Research redesign direction for projects list page

[Che-Zhu]

Goal

Research and define the redesign direction for the projects list page before implementation.

This should align with the v3 product direction in docs/architecture.md: Fulling is moving toward dedicated AI workspaces, where creators configure workspaces and recipients use them. The list page should not blindly inherit the current v2 project/resource dashboard model.

Current code context

• Entry page: app/(dashboard)/projects/(list)/page.tsx
• Data source: getProjects(session.user.id, { sandboxes: true, tasks: true })
• Client shell: HomePageContent
  • refreshes every 3 seconds with router.refresh()
  • handles ?github_install=true popup flow
  • owns status filter state
• UI components:
  • PageHeaderWithFilter renders title, description, and status filters
  • ProjectList maps projects to cards, filters locally, and appends CreateProjectCard
  • ProjectCard shows name, description, status, updated time, and first sandbox publicUrl
  • ProjectActionsMenu exposes start/stop/settings/delete actions
• Current route copy still says My Projects and Manage and monitor your full stack project workspaces.

Research questions

• Should this screen remain /projects for compatibility, or should the product move toward a workspace route/name in a later step?
• What is the primary object users should scan: project, workspace, runtime, template, or recent work thread?
• Which information is decision-critical on the list?
  • mission/purpose
  • runtime status
  • last activity or last run
  • setup readiness
  • knowledge/scripts/skills state
  • share/recipient status
  • problems requiring action
• Should the layout be card grid, dense list/table, or a hybrid depending on workspace count?
• Is 3-second full-page polling still appropriate, or should the page use lighter polling, explicit refresh, route-level cache invalidation, or event-driven updates?
• What should the empty state and primary action be in v3: create workspace, import from GitHub, start from template, or configure runtime?

Deliverable

Produce a short design/research note or implementation issue that defines:

• route and naming direction
• information architecture
• list item/card content
• status model
• empty state
• primary/secondary actions
• refresh strategy
• implementation scope for the first redesign pass

Acceptance criteria

• The redesign direction is documented before UI implementation starts.
• The direction references the v3 workspace model in docs/architecture.md.
• The proposal explicitly decides whether to keep project terminology for now or introduce workspace terminology.
• The proposal includes a concrete first implementation slice, not only broad visual inspiration.