wangxuming/makelore
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
Files
1b1f206dd8aeb7bf69e61b0cd684f70accce9e26
makelore/.project-docs/30-worklog/tasks/20260903-plugin-navigation-design-7c4e2a91.md

4.5 KiB
Raw Blame History

Task: Design unified MakeLore plugin navigation

Identity

  • Task ID: 20260903-plugin-navigation-design-7c4e2a91
  • Mode: Feature
  • Branch: codex/20260903-plugin-navigation-design-7c4e2a91-plugin-navigation-design
  • Worktree: D:\Datas\OthersProjects\makelore-plugin-navigation-design-7c4e2a91
  • Base commit: e9875145b4
  • Owner: codex-root-plugin-nav
  • Status: Ready for Integration

Scope

  • Product and architecture assessment of the current Plugin Marketplace, My Plugins, Project Plugins, local Device Package, and sidebar/router surfaces.
  • Compare the current navigation model with OpenAI's documented Codex Plugins directory and propose one unified MakeLore Plugin surface.
  • Write the task-owned implementation proposal 10-decisions/proposals/20260903-plugin-navigation-design-7c4e2a91__unified-plugin-workspace-spec.md.
  • No product, route, state, server contract, package, or canonical shared-memory changes.

Intent And Constraints

  • Preserve the independent authorities for catalog, Account Library, device bytes, project enablement, Agent assignment, runtime admission, and billing even though their user interface is consolidated.
  • Keep local npm/Git/Plugin/loose-Skill installation conversation-only; the unified page may manage installed Device Packages but must not add an install picker.
  • Treat selected-model Web Search as a model tool, not a Marketplace Plugin.
  • Avoid semantic overlap with concurrent task 20260903-design-message-send-client-8d3f2a71, whose owner confirmed it does not touch Plugin navigation, pages, sidebar, or router.

Outcome

  • Recommend one sidebar entry and canonical /plugins page.
  • The page should use one searchable list with source/status/scope filters rather than three destination tabs: official catalog and locally installed packages are source projections; acquired/installed/enabled are status filters; the active project is a scope filter.
  • One Plugin detail panel should compose description, capabilities, Token Point summary, account/device state, current-project enablement, Agent assignments, and plugin-specific settings while dispatching each mutation to its existing owner.
  • Legacy /plugin-marketplace, /my-plugins, and /project-plugins routes should redirect to deterministic /plugins query states during the navigation cutover.
  • Official Data Service and Game Resource remain Plugin entries. Model Web Search belongs in selected-model capabilities and should not appear as a Plugin card.
  • A unified projection must tolerate partial backend failure: cached official data and local Device Packages remain visible independently.
  • The accepted direction is now frozen as Spec ML-PLUGIN-NAV-001, including the pure Renderer projection Interface, source-qualified item identity, action matrix, exact legacy redirects, partial-failure behavior, accessibility contract, file ownership, tests, four implementation stages, and Definition of Done.

Verification

  • Concurrent Task Gate PASS after the peer owner confirmed disjoint scope.
  • Planning Gate PASS after reading the required project memory, architecture, domain rules, and current integrated state.
  • Inspected current sidebar/router and all three Renderer Plugin pages on exact base e9875145b41a2cb1827de10d27a4fc6a352704ea.
  • Reviewed official OpenAI Plugins documentation for the single directory, marketplace-source grouping, Installed projection, enable/disable behavior, and new-session activation semantics.
  • Re-ran the Concurrent and Planning Gates before writing the implementation Spec; the AI Design peer still has disjoint file and semantic ownership.
  • Re-inspected current Renderer stores, DTO projections, page actions, route/module guards, sidebar entries, unit tests, E2E seams, and canonical Device Package/model tool rules on the recorded base.
  • No executable tests were run because this task makes no product changes; tests would not alter the design conclusion.

Follow-ups

  • Implement PN-01 through PN-04 serially in an isolated client task after explicit implementation authorization.
  • Run fresh Standards and Spec review over the implementation range before promotion to main.

Promotion Candidates

  • If accepted, promote the single-Plugin-surface navigation and state-as-filter distinction into the architecture/module map during the later Integration Gate.
  • Promote the explicit distinction between native selected-model tools and Plugin entries into the user-facing glossary if future UI work makes that distinction visible outside Code.