makelore/.project-docs/30-worklog/tasks/20260817-makelore-module-access-6f2a91c4.md

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: f7171a471a
• 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.
• Corrected the first-review lifecycle gaps: Provider initialization now waits for authenticated policy hydration, a terminal current-user 401 clears both Main and Renderer session state, and global /settings remains available when Code is disabled.

Verification

• Red: module-navigation.test.tsx failed at toBeDisabled() while the static module definition remained enabled.
• Green after review corrections: focused Vitest (module-navigation, auth-store, auth-routes, app-module-provider-gate) — 69 passed.
• Full Vitest — 175 files, 2047 tests passed. An earlier sandboxed run before the review corrections had one environmental EPERM because the test could not create worktree .tmp; every unrestricted full-suite rerun 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.
• First independent Sol review — FAIL: found a cold-start Programming provider race, terminal /api/auth/me 401 fallback, and global /settings misclassification. The task returned to In Progress for corrections and re-review.
• Regression-first correction: the cold-start test failed before the Provider gate fix (initProviders called once while auth was unresolved), then passed after the fix. Added startup/login/refresh 401 lifecycle, Main-session clear, and Code-disabled global-settings coverage.
• Second independent Sol review — FAIL on test evidence only: production logic passed, but /settings Provider initialization and deep/alias pre-layout routing were not explicitly asserted. Added both assertions; the expanded focused and full suites pass.
• Final independent Sol review — PASS: all production behavior and the expanded root/deep/alias route, Provider lifecycle, terminal 401, and pre-layout blocking evidence were accepted with no remaining blockers.

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.