feat: move plugin workspace into project settings

This commit is contained in:
inman
2026-09-07 10:06:37 +08:00
parent f8eee430f4
commit be1764e016
19 changed files with 363 additions and 76 deletions

View File

@@ -0,0 +1,86 @@
# 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`