nexu-io/open-design

Summary On 0.21.0 the MCP server picks its workspace identity by taking the first entry from /api/workspace/directory instead of the activeWorkspaceId that the very same response returns. When a user belongs to more than one workspace and the active one is not first in the list, every MCP read of that user's own local projects fails with: 403 WORKSPACE_PROJECT_PERMISSION_DENIED {"error":{"code":"WORKSPACE_PROJECT_PERMISSION_DENIED","message":"workspace project read is not allowed"}} get_active_context still works (it uses a different endpoint), so the agent can see the project's name and id but cannot read anything inside it — which makes the failure look like a permissions setting the user is supposed to flip somewhere. There is no such setting. Environment Open Design 0.21.0 (launcher-managed install, macOS 15) MCP client: Claude Code, stdio (daemon-cli.mjs mcp --daemon-url …) Account profile prod, session authenticated User is owner of two workspaces, both reported as workspac

Summary Every od automation create and od automation update invocation fails with a temporal dead zone ReferenceError on 0.21.1. The headless automation surface the CLI help advertises for external agents is unusable as a result. ReferenceError: Cannot access 'splitAutomationIds' before initialization at automationContextFromFlags (.../apps/daemon/dist/cli.js:11346:22) at Object.runAutomation (.../apps/daemon/dist/cli.js:11905:29) at async .../apps/daemon/dist/cli.js:851:5 Reproduce Source install, daemon running: export OD_DAEMON_URL=http://127.0.0.1:<daemon-port> node apps/daemon/bin/od.mjs automation create \ --name "example" --prompt "example" --schedule "daily:03:00" automation update <id> --name ... fails identically. automation list, get and run are unaffected, because they do not go through automationContextFromFlags. Cause Not environment specific and not a race. In the bundled apps/daemon/dist/cli.js: 851: await SUBCOMMAND_MAP[first](rest);

First: the pi runtime adapter works beautifully end-to-end — we verified a full run today (spawn via pi --mode rpc, model passthrough deepseek/deepseek-v4-flash, 4 tool_use/tool_result pairs mapped, clean exit 0, 17s total, 99% prompt-cache hit, session-file discovery for native resume engaged). The --list-models TSV parse surfaced 23 models. Great adapter. Two observability suggestions from dogfooding: 1. Record agent_cli_version in execution diagnostics executionDiagnostics.environment.agentCliVersion came back not_collected / agent_cli_version_not_recorded, even though the daemon clearly probes pi --version during runtime detection (the agent list shows the resolved version). Recording the resolved CLI version per run would make version-specific regressions debuggable — e.g. we just hit a pi-ai 0.84.3 packaging defect (#7608) that doesn't exist in 0.80.x, and correlating "which agent CLI version executed this run" would have halved the triage time. The detection probe result cou

What happened? When a generated deck uses a real, self-navigating presentation library (reveal.js is the concrete case we hit) instead of OpenDesign's own .slide.active convention, the deck thumbnail rail shows the same slide (always the first one) for every single slide, even though the main preview pane navigates correctly and each slide's own markup is genuinely different. Observed directly in the product with a real 9-slide deck (screenshot on file, but it contains confidential business content so it isn't attached here - the minimal repro below reproduces the same underlying DOM signature with placeholder content instead). Steps to reproduce Save the attached index.html (bottom of this issue) as an OpenDesign project's deck file, or just open it directly in a browser first to inspect the underlying DOM state described in "Evidence" below (no OpenDesign build needed for that part). Open it as a deck in OpenDesign. Look at the thumbnail rail on the left. All 3 thumbnails render "Sl

Summary PR #7267 fixed a defect in apps/desktop/src/main/updater/store.ts where isOsManagedRootArtifact() matched .DS_Store/Thumbs.db/desktop.ini/.localized by name only, with no lstat check confirming the entry is actually a plain file. That let a directory or symlink squatting on one of those names be silently treated as harmless OS litter — bypassing the empty-root claim check and staying permanently excluded from unexpected-entry corruption validation. packages/download/src/store.ts's ensureManagedBase() has the identical unpatched pattern. It was already flagged once as a follow-up (#7266 → merged via #7268), but that merge duplicated the same name-only check rather than the type-verified version: // packages/download/src/store.ts:27-34 (current upstream/main) const OS_MANAGED_ROOT_ARTIFACTS = new Set([".DS_Store", "Thumbs.db", "desktop.ini", ".localized"]); function isOsManagedRootArtifact(name: string): boolean { return OS_MANAGED_ROOT_ARTIFACTS.has(name); } // line 107, i