[Feature]: Add the Projects dashboard and manual project setup

[roomote-community]

Problem

The dashboard is organized around individual tasks and has no surface for creating or managing a long-running project.

Proposed behavior

Add Projects navigation, a project list, project workspace routes, and a manual setup flow for goals, repositories/environments, members, and roles. Establish Overview, Plan, Work, Activity, Knowledge, and Chat tab shells while fully implementing the draft project Overview and Plan states first.

Reuse existing navigation, forms, repository/environment selectors, authorized-user hooks, and task dashboard patterns. Do not add autonomy, RAG, or GitHub mirroring yet.

Acceptance criteria

• Authorized users can create, view, edit, list, and archive draft projects.
• Role-aware UI and server authorization agree.
• Responsive navigation supports the new Projects area without changing current Tasks behavior.
• Empty states clearly lead users through manual project setup.

Dependency

• [Feature]: Add the project planning domain model and authorization foundation #1037

[roomote-community]

I've analyzed this issue and here's my proposed implementation plan:

1. Land this after [Feature]: Add the project planning domain model and authorization foundation #1037 and consume its typed project services, membership/role grants, repository/environment links, immutable plan-version model, and archive semantics. Keep all project authorization in that shared server layer so UI visibility is advisory and every list/read/create/update/archive operation is independently authorized.
2. Add a protected projects tRPC surface in apps/web/src/trpc/commands/projects/ and register it in apps/web/src/trpc/routers/_app.ts. Expose authorized list/detail, draft creation/update, archive, selector/member data, and Overview/Plan mutations; exclude archived projects by default and preserve linked task/artifact history.
3. Add centralized project route helpers and authenticated routes for /projects, /projects/new, /projects/[projectId], and /projects/[projectId]/edit. Use URL-addressable nested workspace tabs for Overview, Plan, Work, Activity, Knowledge, and Chat so navigation and deep links remain predictable; normalize dynamic project IDs in apps/web/src/lib/telemetry/normalize-path.ts.
4. Add Projects to apps/web/src/components/layout/navigation-items.ts. Let the existing SideNav and NavbarDrawer consume the shared item so desktop/mobile behavior stays aligned and the current Tasks item and matching rules remain unchanged.
5. Build the project list and manual setup flow under apps/web/src/components/projects/. Reuse the environment list/form patterns, shared form primitives, EnvironmentRepositorySelector, environment queries, repository hooks, and authorized-user hooks. The setup flow should collect name/goal, optional repositories and environments, then members and roles, show validation inline, and create a draft that opens its Overview.
6. Implement the draft Overview as an editable summary of goal, setup completeness, linked repositories/environments, members/roles, and archive action. Implement the draft Plan against [Feature]: Add the project planning domain model and authorization foundation #1037's immutable plan-version APIs, showing the current draft and a clear first-plan empty state. Render Work, Activity, Knowledge, and Chat as explicit non-functional “coming later” shells so this issue does not introduce autonomy, RAG, or GitHub mirroring.
7. Make controls capability-driven from the project detail response: users with read access can open the workspace, while create/edit/member/plan/archive actions appear only for matching grants. Treat server rejection as authoritative and surface it consistently rather than relying on useAuthorizedUser().isAdmin alone.
8. Add actionable empty/loading/error states: no projects should lead directly to manual setup; incomplete Overview and Plan states should link to the next setup action; archived projects should disappear from the default list. Use the existing EmptyState/task dashboard patterns and preserve responsive layouts.
9. Add focused tests for project command authorization and archive behavior, list/detail/create/edit flows, role-aware controls, setup validation and selectors, Overview/Plan empty and draft states, navigation matching on desktop/mobile, and telemetry path redaction. Extend navigation-items.test.ts, SideNav.client.test.tsx, NavbarDrawer.client.test.tsx, and normalize-path.test.ts, with new project command/component tests modeled on the environment and access-policy suites.
10. Document the Projects dashboard and manual setup flow in apps/docs/, including draft limitations, role behavior, archive semantics, and the four deferred workspace tabs.

Recommended maintainer defaults for the first release: show Projects to authenticated users who have at least one visible project (and always permit the authorized create path), make the creator the initial project manager, allow a name and goal to create a draft while repository/environment/member setup remains incremental, keep archive reversible at the data layer even if unarchive UI is deferred, and use the role names/capabilities established by #1037 rather than defining a second UI-only role system.

This approach establishes Projects as a distinct top-level planning surface, reuses the existing responsive dashboard and setup controls, and keeps UI/server permissions aligned without changing current Tasks behavior.

Please tag @roomote if you'd like me to implement this, or reply with feedback on the plan.