Canvasight AGENTS.md

AGENTS.md

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.