Patterns
Prioritize project work
Arrange active projects while retaining their next actions and keyboard access.
On this page
User goal
Arrange active projects while retaining their next actions and keyboard access.
Workflow
| Step | Expected behavior |
|---|---|
| 1 | Review each project’s space, title, and next action. |
| 2 | Use the numbered ordering handle to drag a project into a new position. |
| 3 | Alternatively focus the handle and use the arrow-key behavior supplied by ProjectsWorkspace. |
| 4 | Retain the overlay link and task completion as separate controls. |
| 5 | Persist order through the existing planning action and keep the visible order aligned with saved state. |
Decision rules
- Position communicates ordering, not a promised priority algorithm.
- The number belongs to the ordering handle; it is not part of the project identity.
- Reordering must not activate the whole-card navigation link.
- Use the same next-action content later in agenda planning.
Edge cases and recovery
- Check first/last positions and a single-project list.
- A failed persistence call requires a clear recovery decision rather than silent optimistic success.
- Keyboard focus should remain with the reordered project.
- Explicit JavaScript movement must respect reduced-motion preference; the CSS-only rule is insufficient to establish that.
Source references
| File | Responsibility |
|---|---|
| app/components/projects-workspace.tsx | Reorder and keyboard handlers |
| app/components/project-card.tsx | Separate navigation/action layers |
Examples from the app
Actual Radarist components with fictional data. Captured at 2× resolution or higher. Select an image to inspect it full size.
Related topics
Source audit: 2026-10-07 · Revision 0103e2549959 · Documentation v0.1