makelore/.project-docs/10-decisions/proposals/20260906-move-plugins-project-settings-7c91a4e2__project-settings-plugin-navigation.md

Project Configuration owns Plugin navigation

Status

Proposed for integration; implemented and verified in task 20260906-move-plugins-project-settings-7c91a4e2.

Date

2026-09-06

Context

The integrated product exposed one reviewed unified Plugin workspace at /plugins through a standalone Code sidebar entry. Project Configuration no longer contained its predecessor Plugin Services sheet. The user first directed that Plugins belong in Project Settings, then clarified that the workspace must live on the same project page used to configure Agents and Skills rather than replace that page after navigation.

The navigation change must not collapse the existing independent lifecycles for Marketplace acquisition, device installation, project enablement, Agent Skill assignment, runtime authorization, and billing. It also must not restore the retired duplicate sheet or move Main-owned Plugin authority into Renderer code.

Decision

• The Agent/Skill Project Configuration page is the visible owner of the single unified Plugin workspace.
• Its 插件 resource card opens the workspace in a wide same-page drawer. The Project Configuration page remains mounted behind it.
• /project-config/plugins is the canonical deep link for the drawer-open state; it renders Project Configuration rather than a standalone Plugin page.
• /plugins preserves query and navigation state while redirecting to the canonical URL. /plugin-marketplace, /my-plugins, and /project-plugins remain deterministic filtered compatibility redirects.
• The Code sidebar has no standalone Plugin entry.
• The canonical workspace remains accessible before Code Provider initialization and when no project is active, so Marketplace and account/device views do not incorrectly depend on local project selection.
• The existing unified controller, data sources, mutation semantics, authentication, and lifecycle separation remain unchanged.

Rationale

Plugin installation and activation configure resources that projects may use, so Project Configuration is the clearer navigation owner. Reusing the unified workspace avoids competing product surfaces and preserves one authoritative view across Marketplace, Account Library, device packages, and project status. Compatibility redirects protect existing deep links and authenticated return flows while establishing an unambiguous canonical location.

Consequences

• Project Configuration gains a Plugin card beside models, Skills, and knowledge, with access retained in the no-active-project state.
• Closing the Plugin drawer returns to the already-mounted Project Configuration page; Agent assignment actions close the drawer to expose that same page.
• Existing bookmarks continue to work, but tests and new product links should use /project-config/plugins.
• Canonical project memory that names the Code sidebar or /plugins as the sole current entry must be superseded during Integration Mode.
• No backend contract, package trust boundary, runtime permission, billing rule, or native Web Search behavior changes.

Supersedes

• The navigation-only claim that the Code sidebar owns the single 插件 entry and /plugins is the canonical product route.
• It does not supersede the retirement of the duplicate Project Configuration Plugin Services sheet; that implementation remains retired.

Evidence

• User direction: “插件应该在项目设置中”, clarified as “是放在配置agent、skill那个项目页”.
• Focused unit verification: 62/62 passed.
• Electron Plugin journeys: 4/4 passed.
• Full unit, typecheck, lint, and Vite production build passed.

Related

• .project-docs/10-decisions/adr-008-interactive-ai-app-scaffold.md
• .project-docs/30-worklog/tasks/20260906-move-plugins-project-settings-7c91a4e2.md
• src/pages/ProjectConfiguration/index.tsx
• src/pages/Plugins/index.tsx
• src/pages/Plugins/legacy-plugin-redirect.tsx