Skip to content

moooon

Motir

Vibe your whole project. Bring an idea — Motir's three AI layers plan it, track it, and ship it, end to end. You're looking at Motir, built in Motir.

  • Vibe Project
  • Open Source
  • AI Agent
  • AI Loop
1
requests
0
upvotes
145
planned
1,361
shipped

Motir · Work items

MOTIR-360Done

6.5.2 Settings-nav registry + area layout — re-house Workflow / Boards / Estimation / Members / Fields / Components under one chrome

Estimate: 32m · Depends on: 6.5.1, 5.3.6, 5.4.10

The registry and the area shell, per the 6.5.1 design.

lib/settings/projectSettingsNav.ts — the typed registry: one entry per project-settings page ({ id, group, href, icon, labelKey, access }), groups per the design (General / Access / Work / Automation-slot). Access predicates consume the SHIPPED 6.4.3 policy DTO (lib/projects/access.ts + projectAccessService) — never a second role check. TOTAL (mistake #29): a unit test enumerates app/(authed)/settings/project/**/page.tsx routes and fails unless each has exactly one registry entry (and vice versa).

app/(authed)/settings/project/layout.tsx — the area chrome: the grouped nav rendered FROM the registry (filtered by the access predicate), project identity header, back-to-project, active state via the route, the designed narrow-viewport behaviour, the no-active-project empty state preserved. Re-house the existing pages — Workflow, Board (incl. ?board= per-board targeting, unchanged), Estimation, Members & access, and the Epic-5 Fields + Components pages: keep every route, drop the per-page back-crumbs, fit the chrome; retire the hub cards (WorkflowSettingsCard etc. — absorbed by the nav; the Archive card moves in 6.5.3). Entry points: the SidebarNav settings deep-link is unchanged; AppCommandPalette grows per-section entries generated FROM the registry (no hand-kept list). Strings via next-intl (en byte-identical pattern; zh).

A11y: the nav is a labelled navigation landmark, aria-current="page" on the active entry, fully keyboard-operable.

Acceptance criteria

  • The area matches the design panel-for-panel; every existing settings URL resolves unchanged inside the chrome (direct-nav spot checks); the hub cards are gone; ?board= still targets boards.
  • The nav renders from the registry: an entry added in a test renders with zero layout changes; entries filter by the 6.4.3 policy (admin / member / no-access matrix asserted); the totality test fails on a route↔registry drift.
  • Command-palette settings entries come from the registry and deep-link correctly.
  • Axe-clean; token tiers only (colour --el-*, shape element tokens); next-intl threaded; pnpm test:coverage ≥90% on the new files.

Context refs

  • design/projects/settings-area.mock.html + notes (6.5.1) — THE authority
  • lib/projects/access.ts + lib/services/projectAccessService.ts (6.4.3 — the policy the predicates ride); app/(authed)/_components/SidebarNav.tsx + AppCommandPalette.tsx (the entry points)
  • app/(authed)/settings/project/page.tsx + the detail pages (the surfaces re-housed); components/ui/Sidebar.tsx
  • The i18n threading pattern; the 6.1 totality-guard pattern