Feature: Persistent Task List (Work Orders) #1

New issue

Open

opened 2026-01-01 15:49:46 +00:00 by padreug · 0 comments

padreug commented

2026-01-01 15:49:46 +00:00

Owner

Overview

Implement a Persistent Task List for work orders and maintenance tasks that remain visible until explicitly completed. Unlike the current date-based scheduled tasks (NIP-52 Calendar Events), these tasks are not tied to specific dates and persist in a dedicated list until someone completes them.

Use Case Example

Someone needs to replace the handle for a broken axe. This task goes to a list of things that need to be done. A community member can claim it, work on it, and only once it's marked as completed will it disappear from the active list.

Feature Requirements

1. Core Persistent Task Model

Task Properties:

title - Brief description of what needs to be done
description - Detailed instructions or context (optional)
urgency - Priority level (see below)
location - Where the task needs to be performed (optional)
createdBy - Task author (Nostr pubkey)
claimedBy - Who is currently working on it (Nostr pubkey, nullable)
status - Current state: open | claimed | in-progress | completed
createdAt - When the task was created
completedAt - When the task was finished (nullable)
completedBy - Who completed the task (Nostr pubkey, nullable)

2. Urgency Levels

Implement a visual priority system:

Level	Label	Color	Description
1	Critical	Red	Needs immediate attention (safety, blocking other work)
2	High	Orange	Should be done soon
3	Normal	Blue	Standard priority
4	Low	Gray	Can be done when convenient

3. Task Lifecycle / Workflow

┌─────────────────────────────────────────────────────────┐
│                         OPEN                            │
│  (Visible to all, anyone can claim)                     │
└─────────────────────┬───────────────────────────────────┘
                      │ Claim
                      ▼
┌─────────────────────────────────────────────────────────┐
│                       CLAIMED                           │
│  (Assigned to someone, shows who's responsible)         │
└─────────────────────┬───────────────────────────────────┘
                      │ Start Working
                      ▼
┌─────────────────────────────────────────────────────────┐
│                     IN-PROGRESS                         │
│  (Active work being done)                               │
└─────────────────────┬───────────────────────────────────┘
                      │ Mark Complete
                      ▼
┌─────────────────────────────────────────────────────────┐
│                      COMPLETED                          │
│  (Archived, removed from active list)                   │
└─────────────────────────────────────────────────────────┘

Note: Users can also:

Unclaim a task (returns to OPEN, requires communication confirmation)
Skip directly from CLAIMED → COMPLETED for quick tasks

4. UI Components

4.1 Task List View

Separate section from date-based scheduled tasks (possibly a new tab or filter)
Sort by urgency (Critical first, then High, Normal, Low)
Secondary sort by creation date (oldest first within same urgency)
Show task count badges by status (e.g., "5 Open, 2 In Progress")

4.2 Task Card

Title with urgency indicator (colored badge/icon)
Brief description preview
Status badge
Claimed by / Assigned to (with profile avatar)
Action buttons based on current state:
- Open: Claim, Claim & Start
- Claimed (by you): Start, Complete, Unclaim
- In-Progress (by you): Complete, Unclaim

4.3 Create Task Form

Title (required)
Description (optional, markdown support)
Urgency level dropdown
Location (optional)

5. Nostr Event Specification

Consider using a dedicated event kind or extending NIP-52 with a task-specific variant. Options to evaluate:

Option A: New Event Kind

Use a custom kind (e.g., 31923) for persistent tasks
Separate from calendar events conceptually

Option B: Extend NIP-52

Use kind 31922 with a t tag like ["t", "work-order"]
Omit start/end tags to indicate it's not date-bound

Recommendation: Option A provides cleaner separation and avoids confusion with date-based events.

Technical Implementation Notes

Current Architecture

The existing task system in nostr-feed module uses:

Kind 31922 - NIP-52 Calendar Events (date-based)
Kind 31925 - RSVP/completion events
ScheduledEventService.ts - Manages events and completions

Suggested Approach

Create new PersistentTaskService.ts in the nostr-feed module (or new module)
Add new event kind handling in FeedService.ts
Create PersistentTaskCard.vue component
Add "Work Orders" tab/filter in NostrFeed.vue
Reuse existing claiming/completion workflow patterns

Files to Modify/Create

src/modules/nostr-feed/services/PersistentTaskService.ts (new)
src/modules/nostr-feed/components/PersistentTaskCard.vue (new)
src/modules/nostr-feed/components/PersistentTaskList.vue (new)
src/modules/nostr-feed/components/CreatePersistentTaskDialog.vue (new)
src/modules/nostr-feed/services/FeedService.ts (modify)
src/modules/nostr-feed/composables/usePersistentTasks.ts (new)

Acceptance Criteria

Users can create persistent tasks with title, description, urgency, and location
Tasks appear in a dedicated "Work Orders" list separate from scheduled tasks
Tasks are sorted by urgency (Critical → Low), then by age
Users can claim, start, complete, and unclaim tasks
Only completed tasks are removed from the active list
Urgency levels have distinct visual indicators (colors/badges)
Tasks persist across sessions (stored on Nostr relays)
Real-time updates when others claim or complete tasks
Delete functionality for task authors

Future Enhancements (Out of Scope)

Task categories/tags
Due dates (soft deadlines, different from scheduled events)
Comments/discussion on tasks
Task templates for common work orders
Notifications when tasks are claimed/completed
Task history/archive view

## Overview Implement a **Persistent Task List** for work orders and maintenance tasks that remain visible until explicitly completed. Unlike the current date-based scheduled tasks (NIP-52 Calendar Events), these tasks are **not tied to specific dates** and persist in a dedicated list until someone completes them. ### Use Case Example > Someone needs to replace the handle for a broken axe. This task goes to a list of things that need to be done. A community member can claim it, work on it, and only once it's marked as completed will it disappear from the active list. --- ## Feature Requirements ### 1. Core Persistent Task Model **Task Properties:** - `title` - Brief description of what needs to be done - `description` - Detailed instructions or context (optional) - `urgency` - Priority level (see below) - `location` - Where the task needs to be performed (optional) - `createdBy` - Task author (Nostr pubkey) - `claimedBy` - Who is currently working on it (Nostr pubkey, nullable) - `status` - Current state: `open` | `claimed` | `in-progress` | `completed` - `createdAt` - When the task was created - `completedAt` - When the task was finished (nullable) - `completedBy` - Who completed the task (Nostr pubkey, nullable) ### 2. Urgency Levels Implement a visual priority system: | Level | Label | Color | Description | |-------|-------|-------|-------------| | 1 | **Critical** | Red | Needs immediate attention (safety, blocking other work) | | 2 | **High** | Orange | Should be done soon | | 3 | **Normal** | Blue | Standard priority | | 4 | **Low** | Gray | Can be done when convenient | ### 3. Task Lifecycle / Workflow ``` ┌─────────────────────────────────────────────────────────┐ │ OPEN │ │ (Visible to all, anyone can claim) │ └─────────────────────┬───────────────────────────────────┘ │ Claim ▼ ┌─────────────────────────────────────────────────────────┐ │ CLAIMED │ │ (Assigned to someone, shows who's responsible) │ └─────────────────────┬───────────────────────────────────┘ │ Start Working ▼ ┌─────────────────────────────────────────────────────────┐ │ IN-PROGRESS │ │ (Active work being done) │ └─────────────────────┬───────────────────────────────────┘ │ Mark Complete ▼ ┌─────────────────────────────────────────────────────────┐ │ COMPLETED │ │ (Archived, removed from active list) │ └─────────────────────────────────────────────────────────┘ ``` **Note:** Users can also: - Unclaim a task (returns to OPEN, requires communication confirmation) - Skip directly from CLAIMED → COMPLETED for quick tasks ### 4. UI Components #### 4.1 Task List View - **Separate section** from date-based scheduled tasks (possibly a new tab or filter) - **Sort by urgency** (Critical first, then High, Normal, Low) - **Secondary sort** by creation date (oldest first within same urgency) - Show task count badges by status (e.g., "5 Open, 2 In Progress") #### 4.2 Task Card - Title with urgency indicator (colored badge/icon) - Brief description preview - Status badge - Claimed by / Assigned to (with profile avatar) - Action buttons based on current state: - Open: `Claim`, `Claim & Start` - Claimed (by you): `Start`, `Complete`, `Unclaim` - In-Progress (by you): `Complete`, `Unclaim` #### 4.3 Create Task Form - Title (required) - Description (optional, markdown support) - Urgency level dropdown - Location (optional) ### 5. Nostr Event Specification Consider using a dedicated event kind or extending NIP-52 with a task-specific variant. Options to evaluate: **Option A: New Event Kind** - Use a custom kind (e.g., 31923) for persistent tasks - Separate from calendar events conceptually **Option B: Extend NIP-52** - Use kind 31922 with a `t` tag like `["t", "work-order"]` - Omit `start`/`end` tags to indicate it's not date-bound **Recommendation:** Option A provides cleaner separation and avoids confusion with date-based events. --- ## Technical Implementation Notes ### Current Architecture The existing task system in `nostr-feed` module uses: - **Kind 31922** - NIP-52 Calendar Events (date-based) - **Kind 31925** - RSVP/completion events - **ScheduledEventService.ts** - Manages events and completions ### Suggested Approach 1. Create new `PersistentTaskService.ts` in the nostr-feed module (or new module) 2. Add new event kind handling in `FeedService.ts` 3. Create `PersistentTaskCard.vue` component 4. Add "Work Orders" tab/filter in `NostrFeed.vue` 5. Reuse existing claiming/completion workflow patterns ### Files to Modify/Create - `src/modules/nostr-feed/services/PersistentTaskService.ts` (new) - `src/modules/nostr-feed/components/PersistentTaskCard.vue` (new) - `src/modules/nostr-feed/components/PersistentTaskList.vue` (new) - `src/modules/nostr-feed/components/CreatePersistentTaskDialog.vue` (new) - `src/modules/nostr-feed/services/FeedService.ts` (modify) - `src/modules/nostr-feed/composables/usePersistentTasks.ts` (new) --- ## Acceptance Criteria - [ ] Users can create persistent tasks with title, description, urgency, and location - [ ] Tasks appear in a dedicated "Work Orders" list separate from scheduled tasks - [ ] Tasks are sorted by urgency (Critical → Low), then by age - [ ] Users can claim, start, complete, and unclaim tasks - [ ] Only completed tasks are removed from the active list - [ ] Urgency levels have distinct visual indicators (colors/badges) - [ ] Tasks persist across sessions (stored on Nostr relays) - [ ] Real-time updates when others claim or complete tasks - [ ] Delete functionality for task authors --- ## Future Enhancements (Out of Scope) - Task categories/tags - Due dates (soft deadlines, different from scheduled events) - Comments/discussion on tasks - Task templates for common work orders - Notifications when tasks are claimed/completed - Task history/archive view