# Task: Align plugin drawer and project configuration modules

## Identity

- Task ID: 20260907-project-config-plugin-panel-c84e71a2
- Mode: Feature
- Branch: codex/20260907-project-config-plugin-panel-c84e71a2-project-config-plugin-panel
- Worktree: /Users/inmanx/Documents/makelore-plugin-panel
- Base commit: 918f8f80dca61b0f561f96b168e4ef541734d414
- Owner: codex
- Status: Complete

## Scope

- Keep the Project Configuration resource entries in one four-column top row.
- Present Plugins in the same narrow right-side drawer system as Models, Skills, and Knowledge.
- Remove Plugin filters and manual refresh, and expose a direct Skill-like capability list with details and the applicable primary action.
- Keep Plugin details user-facing and capability-oriented, without package/runtime/technical implementation fields.
- Show each configured model's exact name and its supported reasoning strengths in the Models drawer.

## Intent And Constraints

- Preserve `/project-config/plugins` as the canonical deep link and retain all compatibility redirects.
- Preserve the existing unified Plugin controller, Main/store authority boundaries, acquisition, installation, project enablement, assignment, and billing semantics.
- Keep the single Makelore light visual system and update focused unit/Electron E2E coverage.

## Outcome

- Project Configuration now keeps Models, Skills, Knowledge, and Plugins in one four-column resource row.
- The Plugin workspace uses the same 430px right drawer width and shared drawer chrome as the other resources while retaining `/project-config/plugins` deep-link behavior.
- The Plugin drawer now presents one compact list without filters or manual refresh; each row exposes capability copy, details, and the honest next lifecycle action or settled state.
- Plugin details now describe introduction, human-facing capabilities, usage, actions, and necessary settings while omitting package, version, permission-id, runtime, policy, and billing implementation fields.
- The Models drawer now makes the exact model id primary and shows selectable thinking strengths from server-owned capabilities or verified local model profiles; unknown capabilities remain explicitly unknown.
- README describes the updated presentation; shared canonical project-memory updates remain an Integration Gate promotion candidate.

## Verification

- `corepack pnpm exec vitest run tests/unit/plugins-page.test.tsx tests/unit/plugin-workspace-controller.test.ts tests/unit/coding-feature-ui.test.tsx tests/unit/agent-creation-dialog.test.tsx tests/unit/pi-product-artifact.test.ts --maxWorkers=4` — 46 passed.
- `corepack pnpm run typecheck` — passed.
- `corepack pnpm run lint:check` — passed with 5 pre-existing warnings in `src/pages/Home/index.tsx` and `src/pages/Makelore/index.tsx`; no errors.
- `corepack pnpm run build:vite` — passed; existing dynamic-import and chunk-size warnings only.
- `corepack pnpm exec playwright test tests/e2e/plugin-marketplace.spec.ts tests/e2e/project-plugins.spec.ts tests/e2e/project-configuration-skills.spec.ts` — 5 passed; asserts the four-card row, equal drawer widths, direct Plugin list, capability-only details, and unchanged acquisition/device/project authorities.
- `corepack pnpm test` — 1,913 passed and 3 skipped across the normal and pressure suites.
- Isolated Electron screenshots visually confirmed the direct Plugin list, two-action card composition, new description, and capability-only detail hierarchy.

## Follow-ups

- None recorded.

## Integration

- Merged into `main` as `3ecfb74` while preserving the independently restored AI Canvas left project sidebar documentation.
- Restarted the development Electron process from `/Users/inmanx/Documents/makelore` after integration so the visible application uses the merged source tree.

## Promotion Candidates

### Project resource drawer presentation

- Target canonical documents: `.project-docs/30-worklog/current-state.md`, `.project-docs/20-architecture/system-overview.md`, `.project-docs/20-architecture/module-map.md`, `.project-docs/20-architecture/data-flow.md`, and `.project-docs/40-domain/business-rules.md`.
- Proposal: record Project Configuration's single four-card resource row and same-width drawers; describe Plugins as a direct unfiltered capability list with contextual acquisition, installation, project-addition, local-enable, or settled-state actions and capability-only details; describe Models as exact configured model ids plus trusted selectable thinking strengths.
- Evidence: `src/pages/ProjectConfiguration/index.tsx`, `src/pages/Plugins/index.tsx`, `src/pages/Plugins/PluginDetails.tsx`, `src/lib/coding-model-options.ts`, focused unit coverage, five Electron E2E scenarios, typecheck, lint, and production compilation.
- Future impact: future resource settings work must not restore the wide/filter-heavy Plugin workspace or expose plugin implementation metadata in user-facing details, and must not guess unknown model reasoning levels.
- Semantic conflicts: the current canonical documents still describe a wide/filter Plugin workspace and earlier model capability presentation; this proposal supersedes only that presentation while preserving separate acquisition, device-installation, project-enablement, assignment, and Main/store authority boundaries.
- Human confirmation required: no; the user explicitly requested this presentation.