Patterns
Review history without mutating it
Make past-day boundaries understandable while keeping historical work useful to inspect.
On this page
User goal
Make past-day boundaries understandable while keeping historical work useful to inspect.
Workflow
| Step | Expected behavior |
|---|---|
| 1 | Move to a date before Today. |
| 2 | Show Past agenda · Read only and the explanatory history message. |
| 3 | Retain the agenda entries, project identity, and readable task context. |
| 4 | Disable block creation, drag/resize, removal, and task completion for the locked context. |
| 5 | Allow review of Notes for the same date and return to Today when new changes are needed. |
Decision rules
- The date comparison uses local YYYY-MM-DD keys.
- A future date is pre-planning, not historical read-only.
- Locking must be behavioral as well as visual.
- Past agenda access and project archive are distinct concepts.
Edge cases and recovery
- Disabled controls need enough surrounding context to explain the restriction.
- Do not hide the entire historical agenda to enforce editing rules.
- Client locking is not a substitute for server authorization and date validation.
- Capture fixtures show the same fictional day payload at different selected dates to demonstrate the lock presentation; they do not represent real historical records.
Source references
| File | Responsibility |
|---|---|
| app/components/radar-workspace.tsx | Past/future distinction |
| app/components/radar-calendar.tsx | Mutation guards |
| app/components/task-checkbox.tsx | Disabled task state |
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