AGENTS.md

# AGENTS.md

<!-- canvasight-agent-team: disabled -->

## Project Context

Canvasight is an early-stage repo-local Codex plugin. The active product lives under `plugins/canvasight` as a Vite, React, TypeScript, XYFlow, Zustand, and Radix UI application. Preserve room for the final stack, but do not treat the repository as an empty baseline anymore.

The plugin opens a canvas workspace whose v2 domain model is `Page -> Group -> Task Node | Asset Node`. Task Nodes own Markdown instructions and Codex mode; Asset Nodes each reference one Canvasight-managed project file and may start a downstream Run; Groups are non-nested semantic containers whose Run includes only direct members, internal Edges, and member assets. Task Nodes do not accept new inline attachments: file selection, drop, and file/image paste create Asset Nodes. Legacy Task attachments remain readable, runnable, exportable, removable, and explicitly promotable without silent data loss. Edges express dependency/evidence/decision/flow rather than Group containment. The web app is served by a project-level local daemon that outlives thread-local MCP shim processes. Normal plugin use renders Canvasight inside a Codex native widget through `open_canvasight`; callers must read the active task's `CODEX_THREAD_ID` and pass it as `threadId` because MCP child processes may not inherit it and Chat / Plan / Goal preflight requires an explicit target. The widget directly hosts the built app instead of iframe-loading localhost. Native widget JSON APIs route through the app-only `canvasight_widget_api` MCP tool, which proxies a strict allowlist to the daemon; the sandboxed widget must not depend on direct localhost fetches for startup or editing. Widget CSP must still include the daemon's exact origin before resource delivery for daemon-backed attachment assets. Native open tool results must not publicly expose daemon `127.0.0.1` URLs or tokens. Running a Task/Asset sends Markdown for that node plus downstream children; running a Group sends only its contained scope to the current Codex thread through the widget host bridge after native Chat / Plan / Goal preflight. The widget bridge may use standard MCP Apps `ui/message` or the Codex/OpenAI compatibility `window.openai.sendFollowUpMessage`; both count as native widget host bridge transports, not browser fallback. A successful MCP App handshake makes `sendMessage` callable even if the host omits the advisory `hostCapabilities.message` declaration; only the send Promise result determines sent/failed. Browser URLs and bare dev pages are fallback/development surfaces: after a current-thread claim they only queue payloads for `await_canvasight_run`; they must not report app-server `turn/start` as a successful Run path.

`@Canvasight` requests to generate a new bitmap route through `canvasight-imagegen`: verify or open the native widget first, capture Graph Context, use the system imagegen Skill, then call `add_canvasight_generated_images`. That tool accepts only inspected PNG/JPEG/WebP files under the current project or `$CODEX_HOME/generated_images`, copies them into `.scatter/assets`, and atomically adds ungrouped Asset Nodes to the captured Page's right side. Page switches never retarget the import; successful mutation replay is idempotent across daemon restarts.

`open_canvasight` tool completion means only that the MCP call created a provisional `OpenAttempt`; it is not proof that the canvas opened. Callers must pass its `sessionId`, `openAttemptId`, and exact `threadId` to `await_canvasight_widget_ready`. Native opening succeeds only when that result is verified for a concrete fullscreen `widgetInstanceId` with React mounted, project hydration complete, and a visible non-zero canvas. Until that acknowledgement is observed, the result is `unverified`; agents must not say the canvas is "opened", "ready", or "fixed" based on tool output, another renderer, resource reads, daemon health, browser fallback, or synthetic harnesses alone.

Use `design.md` as the product and UI design baseline when adding user-facing screens.

## Working Rules

- Read the existing file tree before making changes.
- Keep changes scoped to the user's request.
- Do not rewrite or remove user changes unless explicitly asked.
- Prefer small, reviewable commits and focused files over broad refactors.
- Add dependencies only when they solve a concrete implementation need.
- When introducing a build system, document the commands in this file and in the project README if one exists.

## Implementation Standards

- Follow the conventions already present in the codebase once source files exist.
- When Canvasight is already open or recently attached, treat medium or complex follow-up requests as active canvas context. Prefer `write_canvasight_graph` before direct execution when the request benefits from decomposition, dependencies, stages, or visual review. Do not force graph writing for small direct commands, simple questions, Canvasight Run payloads, or requests that explicitly ask for immediate direct execution.
- Before a Graph Writer write, classify every unresolved item as blocking-framework or non-blocking-backlog. If an unanswered choice could change identity or authority, primary audience, included content/media types, language coverage, content mode, framework dimensions, target scope, key relationships, write behavior, required coverage, or acceptance, `ask_canvasight_framework_questions` is mandatory before any write or completion claim. Never write first and then list that choice as “待确认”, “待定”, `TBD`, `open question`, or `unknown`. First inspect the repository, current Page, user context, and applicable Skills. Group at most three high-priority questions into the inline card; the cap does not permit writing while another independent blocker remains. Only a question that is itself the requested exploration object, later research that cannot change this pass, or a decorative preference that changes neither structure nor acceptance may remain as explicitly non-blocking follow-up work. After the visible answer message reacquire graph context before continuing. If the tool or inline UI is unavailable, ask concise text questions; never open Canvasight or guess a consequential answer as the fallback.
- Before changing an existing Canvasight Page, call `get_canvasight_graph_context` and preserve its `contextId`, `documentRevision`, and `documentVersion`. Select Page behavior from the user's write intent: use `merge-active-page` for continue/refine/expand/remove requests that target the captured Page, `append-page` for an explicitly new canvas, `replace-active-page` only for an explicit current-Page rewrite, and `replace-document` only for an explicit full reset. Modern `merge-active-page` calls must also send that context's `documentRevision` as `expectedRevision` plus a stable `clientMutationId` across retries.
- AI graph generation combines intent, primary domain, optional secondary domain, maturity, and output topology through `frameworkManifest`. Submit coverage, `semanticStructure` responsibilities, and explicit `semanticRelationships` for covered-node edges. Decompose by independently understandable, executable, decidable, verifiable, or deliverable responsibilities; never use node counts, body length, coverage counts, branch counts, or fixed depth as quality thresholds. Semantic order is not automatically a dependency: articles, product surfaces, capabilities, verification, and ordered work must branch unless an edge records a real containment, dependency, sequence, evidence, decision, navigation, or flow relationship. Validation failures are internal repair instructions: correct the candidate and retry, up to three rounds, before writing or reporting completion. Do not expose a raw violation list as the delivered user result.
- Skill composition has three separate layers. Professional canvas-level Skills may lead content through `skill-led`, but Canvasight remains the sole Page/node/edge/revision writer and always converts layout advice to horizontal topology. AI node assignments require the global opt-in, a clear current-project Skill-description match, a rationale, and visible `$skill-name` node text; user-explicit or manually typed `$Skill` remains allowed when the opt-in or catalog is unavailable. Never add a hidden persisted node Skill field or let an external Skill write `.scatter` directly.
- Prefer typed, explicit data structures for product state and UI contracts.
- Keep business logic separate from presentation when the framework makes that practical.
- Make UI components reusable only after the same pattern appears more than once or clearly belongs to a shared system.
- Avoid placeholder-only screens for core flows; build the usable workflow first.
- Keep canvas state, persistence, and MCP contracts explicit. Do not hide run behavior inside presentation components when it can live in store or runtime helpers.
- `.scatter` v1 and v2 must remain readable. Opening v1 is read-only migration; the first Asset/Group/`parentId` mutation upgrades once to v2, creates `.scatter/scatter.v1.backup.json` only if absent, and the schema must never downgrade afterward. Asset deletion never deletes its managed file.
- Group membership is single-owner, non-nested containment through Task/Asset `parentId`; never persist containment as an Edge or allow an Edge endpoint to be a Group. Asset graph writes may only reuse server-validated files under the current project's `.scatter/assets` directory.
- Edge parentage is a hard single-predecessor invariant, independent of Group `parentId`: a Task/Asset may be a root with zero incoming Edges, but once connected as a target it may have exactly one incoming Edge. A node may still fan out to multiple targets. Enforce the same target-cardinality rule before every manual/UI mutation, document save, AI graph write, retry, import, and concurrent merge; never introduce or increase a second incoming Edge, silently replace the existing parent, or silently delete an Edge from legacy dirty data. Legacy dirty data may be saved only when each target's violation is unchanged or reduced so the user can repair it explicitly. A rejected second-parent connection must leave the existing Edge, selection, history, and document revision unchanged. Concurrent branches that independently add different parents to one target are a semantic conflict, not an automatic merge.
- Preserve Canvasight's current XYFlow Edge endpoint geometry. With the current 20 px left/right Handles, the `sourceX` / `targetX` values passed to `ScatterEdge` are the Handle's outer edge, not the Handle center or visible node boundary. Persistent Edge paths and SVG caps must convert that coordinate inward by half the Handle width: left uses `x + 10`, right uses `x - 10`. Do not use the raw coordinate directly, and never use the outward inverse (`left: x - 10`, `right: x + 10`); both leave a visible gap. If Handle size or placement changes, update the half-width conversion with it.
- Keep Edge attachment geometry and connect-button occlusion as separate responsibilities. Geometry makes a persistent Edge touch the visible Task/Asset boundary; stacking makes the opaque connect button cover the Edge/path/cap while the button is visible. Keep `.react-flow__nodes` at `z-index: auto` and preserve the relative order Group `0` < each persistent Edge SVG `1` < Task/Asset `2`. Never move an Edge endpoint outward, disable the whole Edge's pointer events, or raise a Group above its Edges to hide a button-overlap defect; the Edge interaction path must remain clickable and selectable.
- Any change to XYFlow Handles, `ScatterEdge`, node bounds, or canvas layer CSS requires real-browser geometry and interaction acceptance at representative zoom levels, including the current approximately 72% QA viewport. For existing Edges on both the left and right sides, transform the SVG path endpoints into screen coordinates and compare them with the visible node's `getBoundingClientRect()` boundary; each absolute gap must be at most `0.5 CSS px`. Verify non-hover attachment, hover/focus/selected button occlusion, `elementsFromPoint` button precedence, Group-internal Edge visibility, Edge click/selection highlighting, and a real drag-to-connect flow with zero console errors or warnings. Static source assertions and screenshots alone do not satisfy this gate; the browser check must be capable of rejecting both raw/direct coordinates and the outward inverse.
- Page `viewState.collapsedGroupIds` is human-owned presentation state. Persist it, exclude it from semantic conflict detection, preserve the current value through AI writes/rebases, and never accept it as AI-authored graph intent.
- Keep concurrent document writes explicit and backward compatible. Modern manual/UI saves use base, local, and current documents for three-way merging, persist revision history and bounded mutation receipts in `.scatter/revision-state.json`, and must keep mutation replay idempotent across daemon restarts. Modern AI `merge-active-page` writes use the captured `contextId`, `expectedRevision`, and stable `clientMutationId` for daemon-side validation and rebase against the captured target Page; switching the visible Page must never retarget the write. During a human-versus-AI conflict, current user semantic edits and manual positions win on the original Page, while the complete AI candidate is preserved in a uniquely identified conflict copy; if the target Page was deleted, preserve the AI candidate as a recovery copy without restoring the deleted Page. Mutation receipts must make successful writes and conflict/recovery copies idempotent across daemon restarts. Legacy document saves and AI calls without a valid modern context remain strict revision-checked paths and return stale/context errors instead of entering the rebase path.
- Use the existing app icon registry in `src/components/ui/icon.tsx` and SVG assets under `src/assets/icons` before adding another icon path.
- Git-backed plugin installs must be runnable from the installed snapshot without `node_modules`, package-manager lifecycle scripts, or network access. The editable MCP source is `mcp/server.source.mjs`; `mcp/server.mjs` is the generated self-contained installed entry. Rebuild and verify that entry whenever MCP source or bundled dependencies change.
- When MCP runtime behavior changes, bump the plugin version in `.codex-plugin/plugin.json`, `package.json`, `package-lock.json`, and `mcp/server.source.mjs` `SERVER_VERSION` together, then regenerate `mcp/server.mjs`. Codex may keep versioned plugin cache entries, so changing runtime code without a version bump can leave users running stale MCP servers.
- MCP list tools that can expose large user-authored content should return lightweight summaries by default and provide a separate by-id read path for full content.
- Persistent user-asset features with capacity limits must reject or ask for explicit replacement at the limit. Do not silently evict older user data through list slicing or hidden cleanup.
- Managed `.svg` files are first-class Image Assets. Treat the `.svg` extension under `.scatter/assets` as authoritative even when upload MIME is empty or generic, re-infer legacy attachment `kind`/MIME during normalization, and fail closed when a non-`.svg` file merely claims `image/svg+xml`. SVG previews must be sanitized before display and rendered only as passive `<img>` content; never inject markup or use `object`, `embed`, `iframe`, or `dangerouslySetInnerHTML`. Browser/dev and native-widget loaders must remove executable elements, event attributes, `foreignObject`, external references, and unsafe CSS URLs while preserving safe `viewBox`, gradients, local fragments, and presentation styles. Keep the managed source file byte-preserving, serve SVG assets with `image/svg+xml`, `X-Content-Type-Options: nosniff`, and a restrictive resource CSP, and never regress source SVG images into the ordinary file-card/icon layout.
- Plugin self-update installs the complete immutable plugin snapshot from the latest official GitHub Release through the `canvasight-local` marketplace; it must never patch individual cached MCP, Skill, UI, or asset files. Keep plugin name `canvasight`, plugin id `canvasight@canvasight-local`, marketplace name `canvasight-local`, official repository `Niall-Young/Canvasight`, and release branch `stable` stable unless an explicit migration is designed.
- The updater must compare versions before any mutating CLI call. Equal versions are a zero-mutation success, newer local versions are never downgraded, unrecognized versions fail closed, and local checkouts or custom forks are never replaced. A real update must verify official source, Release/manifest version agreement, installed version, and rollback any marketplace switch that occurred before a later failure.
- Generic plugin updates must not read, rewrite, migrate, delete, or recreate `.scatter/scatter.json`, `.scatter/assets`, `~/.canvasight`, project source, other plugins/Skills, local development checkouts, or unrelated Codex configuration. Data-format migrations require a separate backward-compatible design.
- `main` is the development branch. After the tagged version passes the release matrix, publish and verify the complete GitHub Release first, then fast-forward `stable` to that exact tag commit as the final release step. If publishing or verification fails, do not change `stable`; if the final `stable` fast-forward fails, delete the just-published Release and leave the previous `stable` untouched. Release recovery must not depend on force-pushing, rewinding, or deleting a protected `stable` branch. Do not publish a Release whose tag, manifest, package, MCP `SERVER_VERSION`, generated MCP bundle, or built web snapshot disagree.
- Release web builds must be reproducible across checkout paths and operating systems: never compile a developer or CI absolute project path into `dist`, keep plugin text inputs LF through `.gitattributes`, and make release validators accept CRLF checkout input where Windows can still supply it.

## Design Standards

- Use `design.md` as the source of truth for layout, tone, interaction patterns, and visual direction.
- Product surfaces should be direct and work-focused. Avoid marketing-style hero pages unless the request is specifically for a landing page.
- Prioritize dense but readable interfaces: clear hierarchy, compact controls, predictable navigation, and strong empty/loading/error states.
- Use established controls for their jobs: selects for switching records, tabs for view modes, toggles for binary settings, sliders or numeric inputs for values, and icon buttons for common tools.
- Preserve the current workspace model: compact topbar, canvas-first layout, task nodes as the primary editable objects, contextual drawers for task lists and Markdown/run output, and node-level Codex mode controls.
- When changing iconography, update both the visual asset and the semantic command it represents. For example, the task-list drawer should use a list icon, and the Goal Codex mode should use a target-style icon.

## Verification

When commands exist, run the narrowest useful verification before finishing:

- Lint/typecheck for code changes.
- Unit tests for shared logic changes.
- Browser-visible verification for browser UI changes.
- Build verification before claiming a project is ready to run or deploy.

Native widget changes have a separate mandatory acceptance gate:

- Synthetic VM, DOM, metadata-shape, postMessage, MCP smoke, build, and plugin validation are supporting checks only. They cannot replace native-host acceptance.
- Install the exact delivered plugin version. If the version changed while Codex Desktop was already running, reload/restart the Codex host before creating and tagging a new task; creating a task alone can retain the app-level plugin registry snapshot. Then invoke the normal `@Canvasight` / `open_canvasight` path.
- Observe the instance-bound fullscreen ready acknowledgement, confirm the full canvas is visible, upload an image and verify its daemon-proxied preview, create and collapse/expand a Group, confirm a Group Run reaches the same Codex task through that accepted instance, and verify late metadata cannot return the UI to Connecting.
- A browser or bare-dev fallback can diagnose canvas and daemon behavior, but cannot satisfy any native-widget acceptance item.
- If the real Codex native-host check cannot be performed, record the exact missing evidence and mark the delivery `unverified`. Do not close the relevant issue as resolved and do not claim the native widget is fixed, opened, ready, or successfully delivered.

If verification cannot be run because the project has no scripts yet, state that clearly in the final response.

## Current Commands

Canvasight is currently implemented as a repo-local Codex plugin under `plugins/canvasight`.

Run plugin commands from `/Users/niallyoung/Desktop/Canvasight/plugins/canvasight`:

- Normal plugin opening reads the active task's `CODEX_THREAD_ID`, passes it as `threadId` to `open_canvasight`, and renders the native widget for that task. If `open_canvasight` is not visible, use `tool_search` for `canvasight open_canvasight render_canvasight_canvas_widget` before declaring the native tool unavailable. Use `open_canvasight_browser_fallback` only when the user explicitly requests the fallback or for diagnostics.
- `get_canvasight_graph_context` returns the active Page's lightweight Task/Asset/Group summaries, Group membership, asset `id`/`relativePath` handles, Edges, positions, Page summary, `documentRevision`, `documentVersion`, and daemon-held `contextId` before an AI update. Modern `write_canvasight_graph` `merge-active-page` calls submit that `contextId`, its revision as `expectedRevision`, and a stable `clientMutationId`; after validation, the daemon rebases onto the captured target Page and may return `written`, `merged`, or `conflict-copy`. Graph writes support Task, managed Asset, Group, and Task/Asset `parentId`, reject Group Edges/nesting/unmanaged assets, and cannot alter collapsed view state. Legacy calls remain strict revision-checked operations. Every AI-created or AI-relayouted graph uses a two-level left-to-right topology: Group/ungrouped objects first, then members horizontally inside each Group. Domain, output, `graphType`, reading order, and task sequence never create a vertical exception. Legacy `vertical` and `grid` inputs are compatibility aliases normalized to horizontal. Normal AI writes use `layoutPolicy: auto`; use `preserve-explicit` only to protect explicitly user-authored coordinates, and use `relayout-page` after topology changes that invalidate the whole Page's placement. Existing nodes retain their latest manual coordinates during rebase; AI layout applies only to newly added nodes.
- `add_canvasight_generated_images` requires the exact current `threadId`, a context captured before generation, its revision, a stable mutation ID, and one to sixteen final image paths. It preserves sources, rejects unsafe or oversized input without partial writes, creates one managed Asset Node per image on the captured Page, and returns only lightweight node/asset identifiers plus project-relative paths.
- Native open requires an explicit current `threadId` and normal mode preflight. Public output returns `sessionId` plus `openAttemptId` but must not expose daemon URLs or tokens; widget-only session data stays in `_meta.widgetData`. A completed open response remains provisional until the fullscreen instance emits complete ready evidence.
- Native widget session/API requests use the app-only `canvasight_widget_api` MCP proxy. Browser/dev surfaces keep direct daemon fetches. Resource reads must wait for the daemon so widget CSP contains its exact origin before attachment assets can load.
- `ask_canvasight_framework_questions` binds the separate `ui://widget/canvasight/framework-questions.html` inline resource. It reuses the Canvasight React bundle, design tokens, and `app.css`, but must not start the daemon, create a Canvasight Session, request fullscreen, load the workspace shell, or persist choices to `.scatter`. Answers return through `ui/message` with `window.openai.sendFollowUpMessage` compatibility and lock only after that Promise succeeds.
- Native Run uses the widget host bridge and is sent only when the bridge Promise resolves. Browser/dev Run is diagnostic-only: after a current-thread claim it queues for `await_canvasight_run` and must not report app-server `turn/start` as sent.
- `npm run dev` starts or reuses the project-level persistent Canvasight dev server at `http://127.0.0.1:5173/`, stops stale version-mismatched processes, and exits after the server is ready. Bare dev mode uses the latest explicit thread claim, resolves that task's Codex project, and returns `unbound_dev_session` when no claim exists; it must not invent a project from the dev process environment or show a normal-use project-path gate.
- MCP shim and daemon lifecycle must remain version-matched, single-flight, diagnosable, safe across stale installed/source processes, and bounded in lifecycle-log size. A closed transport requires a reloaded or new Codex task; localhost fallback is not a native recovery.
- `npm run dev:stop` stops the persistent Canvasight dev server.
- `npm run dev:status` reports whether the persistent Canvasight dev server is `running`, `stopped`, or `stale` because the recorded dev server or daemon `serverVersion` no longer matches the current package version.
- `npm run dev:foreground` starts Vite in the foreground when live terminal logs are explicitly needed.
- `npm run daemon` manually starts the project-level Canvasight daemon for development/debugging.
- `npm run daemon:stop` manually stops the project-level Canvasight daemon for development/debugging.
- `npm run typecheck` runs TypeScript checks.
- `npm run build` regenerates the self-contained MCP entry, runs TypeScript checks, and builds the web app into `dist/`.
- `npm run build:mcp` regenerates the self-contained installed MCP entry from `mcp/server.source.mjs`.
- `npm run check:mcp-bundle` rebuilds the MCP entry in memory and fails if the committed `mcp/server.mjs` is stale.
- `npm run preview` previews the built web app.
- `npm run test:markdown` verifies node Run Markdown includes the current node plus downstream children in stable order.
- `npm run test:rich-text` verifies supported node-body Markdown parsing and serialization, safe links, legacy plain text, unknown-syntax preservation, and rich-text editor source contracts.
- `npm run test:asset-presentation` verifies Asset extension/MIME mapping, supplied SVG registry availability, natural-ratio media, ordinary-file filename/size layout, the absence of visible Asset classification, and hover/focus/open More behavior.
- `npm run test:node-creation` verifies the shared Task/file/media creation menu for Task/Asset side pluses and blank-canvas connection drops, single-file category validation, and connection revalidation before atomic node/Edge commit.
- `npm run test:task-attachments` verifies Task upload controls and inline-attachment creation paths stay removed, Task drop/paste routes files to Asset Nodes, and legacy Task attachments remain readable, removable, promotable, runnable, and save-compatible.
- `npm run test:svg-asset` verifies extension-authoritative SVG classification, legacy metadata normalization, response security headers, native/browser sanitization, passive `<img>` rendering, and preservation of safe vector structure.
- `npm run test:single-parent` verifies the shared manual Edge rule rejects a second incoming parent before mutation; MCP and concurrency suites cover daemon writes, revision stability, legacy repair, and concurrent parent conflicts.
- `npm run test:skills` verifies `$` query detection, fuzzy Chinese/name matching, token replacement, and multiple node-body Skill tokens.
- `npm run test:dev-server` verifies the persistent dev server lifecycle.
- `npm run test:mcp` runs the MCP smoke test, including daemon persistence across MCP process restarts, concurrent daemon single-flight, stdout-close/EPIPE handling, and newline plus `Content-Length` JSON-RPC transports.
- `npm run test:concurrency` verifies cross-task three-way document merging, conflict copies, mutation replay and daemon-restart idempotency, and concurrent AI graph-writer behavior.
- `npm run test:plugin-distribution` copies the plugin without `node_modules` and verifies that the installed MCP entry completes registration with all expected tools.
- `npm run test:update` verifies read-only checks, complete stable installs, protected local/custom/development sources, rollback, version boundaries, and cross-platform CLI invocation without touching real Codex state.
- `npm run release:prepare -- <version>` synchronizes the release version across plugin manifest, package metadata, and MCP source, then regenerates the committed MCP and web distribution artifacts. Use a plain stable semver such as `0.4.11`.
- `npm run release:verify -- <version>` performs the read-only release gate for synchronized version fields, plugin identity, required built assets, and valid Skill frontmatter.
- `npm run diagnose:mcp` performs an isolated MCP registration probe without opening the canvas or starting the daemon. It reports manifest Node-command resolution, executable/runtime details, `initialize`, `tools/list`, required open tools, and lifecycle-log stages; on Windows it can also be run as `node .\tests\mcp-registration-probe.mjs` to avoid PowerShell script-policy shims.

Plugin validation runs from the repo root:

- `python3 /Users/niallyoung/.codex/skills/.system/plugin-creator/scripts/validate_plugin.py /Users/niallyoung/Desktop/Canvasight/plugins/canvasight`

After installing, reinstalling, or upgrading `canvasight@canvasight-local`, reload/restart Codex Desktop before verifying MCP tools in a newly created and newly tagged task. Existing tasks do not hot-refresh plugin tools, and a new task created by the same unreloaded desktop process can still retain its app-level plugin registry snapshot.