wangxuming/makelore
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: enforce per-user module access in Makelore

Browse Source
This commit is contained in:
brother7
2026-08-17 08:51:15 +08:00
parent f7171a471a
commit d16922f18c
12 changed files with 457 additions and 35 deletions
Download Patch File Download Diff File Expand all files Collapse all files

59
.project-docs/30-worklog/tasks/20260817-makelore-module-access-6f2a91c4.md Normal file
View File

@@ -0,0 +1,59 @@
# Task: Implement MakeLore module access navigation
## Identity
- Task ID: 20260817-makelore-module-access-6f2a91c4
- Mode: Feature
- Branch: codex/20260817-makelore-module-access-6f2a91c4-makelore-module-access
- Worktree: D:\Datas\OthersProjects\makelore-module-access-6f2a91c4
- Base commit: f7171a471ab1a39380ef666b1e1be9a1f689e43f
- Owner: codex
- Status: Ready For Integration
## Scope
- Consume the current user's Works Square `module_access` policy through an Electron Main-owned safe projection.
- Default the four policy fields to enabled for old or partially deployed server responses.
- Grey out disabled Code, Canvas, Learning, and Robot cards, prevent chooser navigation, and block direct module routes before their workspaces initialize.
- Add focused Main route, Renderer store, chooser, and top-level route regression coverage; update README current behavior.
## Intent And Constraints
- Keep Works Square credentials and the raw `/api/auth/me` profile in Electron Main; Renderer receives only four booleans.
- Treat `design` as the server policy key for the existing client `painting` module id without renaming the integrated module model.
- Keep missing policy objects or keys enabled for backward compatibility; retain the last known same-session policy when refresh is temporarily unavailable.
- Prevent disabled Programming routes from initializing providers and prevent all disabled module routes from mounting `MainLayout`.
- Treat this as a client interaction/navigation gate, not as an API authorization boundary.
- Work only in the isolated linked worktree and do not modify the occupied `main` integration worktree.
## Outcome
- Red regression reproduced the reported symptom: a user policy with `learning: false` still rendered an enabled, navigable Learning card.
- Implemented a shared four-field policy normalizer, Main-owned `/api/auth/me` projection, startup/login/refresh policy hydration, chooser disable state, and direct-route guard.
- Bumped the persisted authentication state to schema version 2 so existing installations normalize the new policy field during upgrade; a new login falls back to all-enabled rather than inheriting another account's cached policy.
- Disabled Programming routes no longer initialize providers, and all four disabled module families redirect before `MainLayout` or module workspaces mount.
## Verification
- Red: `module-navigation.test.tsx` failed at `toBeDisabled()` while the static module definition remained enabled.
- Green: focused Vitest (`module-navigation`, `auth-store`, `auth-routes`, `app-module-provider-gate`) — 58 passed.
- Full Vitest — 175 files, 2036 tests passed. The first sandboxed run had one environmental `EPERM` because the test could not create worktree `.tmp`; the unrestricted rerun of the same suite passed completely.
- TypeScript `tsc --noEmit` — passed.
- Scoped ESLint for all changed TypeScript/TSX files — passed.
- Vite production build — passed (Renderer, Electron Main, and preload); existing chunk-size/dynamic-import warnings remain unchanged.
- `git diff --check` — passed.
- Electron E2E was not extended because the shared fixture deliberately bypasses authentication and cannot express a Main-owned Works `/api/auth/me` policy; the user-visible chooser and direct-route behavior are covered at rendered App/Router seams.
## Follow-ups
- Integration owner: merge this reviewed feature branch into the occupied `main` worktree without overwriting its existing task record.
- Release smoke: after deploying the Works Square module-access migration/API and packaging the updated client, disable each module for a real user, restart Makelore, verify the matching card is grey/non-clickable, and verify a direct deep link returns to the chooser.
## Promotion Candidates
- Target: canonical business rules and authentication/data-flow documentation during Integration Gate.
- Proposal: record that Makelore reads the per-user four-module policy through Electron Main at session startup, defaults missing policy fields to enabled, blocks disabled module entry and direct routing before module initialization, and does not treat this UI gate as server authorization.
- Evidence: focused Main/Store/chooser/App regressions and final verification in this task.
- Future impact: new top-level modules must define an explicit server policy mapping and route guard; backend APIs still require their own authorization.
- Semantic conflicts: none identified with the existing Main-owned Works session or four-module model.
- Human confirmation required: no; this implements the user-approved operations behavior and preserves the server's default-open compatibility contract.