11 KiB
description
| description |
|---|
| Task list template for feature implementation |
Tasks: Archive Curator
Input: Design documents from /specs/001-archive-curator/
Prerequisites: plan.md (required), spec.md (required for user stories), research.md, data-model.md, contracts/
Tests: The examples below include test tasks. Tests are OPTIONAL - only include them if explicitly requested in the feature specification.
Organization: Tasks are grouped by user story to enable independent implementation and testing of each story.
Format: [ID] [P?] [Story] Description
- [P]: Can run in parallel (different files, no dependencies)
- [Story]: Which user story this task belongs to (e.g., US1, US2, US3)
- Include exact file paths in descriptions
Path Conventions
- Single project:
src/,tests/at repository root - Web app:
backend/src/,frontend/src/ - Mobile:
api/src/,ios/src/orandroid/src/ - Paths shown below assume single project - adjust based on plan.md structure
Phase 1: Setup (Shared Infrastructure)
Purpose: Project initialization and basic structure
- T001 Create backend and frontend directory structure in
backend/src/andfrontend/src/ - T002 Initialize Rust backend crate in
backend/Cargo.toml - T003 Initialize SvelteKit frontend in
frontend/package.json - T004 [P] Add repository-wide formatting and lint configs in
backend/rustfmt.tomlandfrontend/.prettierrc - T005 Add base README for local run notes in
README.md
Phase 2: Foundational (Blocking Prerequisites)
Purpose: Core infrastructure that MUST be complete before ANY user story can be implemented
⚠️ CRITICAL: No user story work can begin until this phase is complete
- T006 Implement configuration model and validation in
backend/src/config.rs - T006a Implement root non-overlap validation (fail-fast) in
backend/src/config.rs - T007 Implement root boundary validation helpers in
backend/src/services/path_guard.rs - T008 Implement read-only mode enforcement guard in
backend/src/services/read_only.rs - T009 Implement state storage access layer in
backend/src/services/state_store.rs - T010 Implement audit log append-only writer in
backend/src/services/audit_log.rs - T011 Implement list-file parser and matcher in
backend/src/services/list_file.rs - T012 Implement preview/confirm action model in
backend/src/services/preview_action.rs - T013 Implement filesystem operations facade in
backend/src/services/ops.rs - T014 Add HTTP server bootstrap and routing in
backend/src/main.rs - T014a Enforce bind address defaults/local-network restriction in
backend/src/main.rs
Checkpoint: Foundation ready - user story implementation can now begin in parallel
Phase 2.5: Safety & Compliance (Mandatory for destructive operations)
Purpose: Enforce constitution safety guarantees before any deletion work
- T015 Implement global read-only mode block in
backend/src/services/read_only.rs - T016 Enforce root-path boundaries for all filesystem operations in
backend/src/services/path_guard.rs - T017 Implement single-writer guard for destructive operations in
backend/src/services/ops_lock.rs - T018 Implement dry-run preview + explicit confirmation flow in
backend/src/services/preview_action.rs - T019 Implement two-stage deletion (trash/staging) in
backend/src/services/ops.rs - T019a Enforce hard-delete disabled by default and require explicit config + confirmation in
backend/src/services/ops.rs - T020 Enforce symlink-safe deletion in
backend/src/services/ops.rs - T021 Append-only audit log for every mutation in
backend/src/services/audit_log.rs - T022 Enforce whitelist protection for directory-level actions in
backend/src/services/ops.rs - T023 Implement list-file edit preview + atomic write in
backend/src/services/list_file.rs
Checkpoint: Safety guarantees verified - destructive workflows can now begin
Phase 3: User Story 1 - Untagged Directory Decisions (Priority: P1) 🎯 MVP
Goal: Review untagged directories with a collage, keep or delete safely, and preview list-file changes
Independent Test: Can review an untagged directory, resample collage, keep (move to kept root), preview delete with list-file matches, and confirm delete with audit entry
Implementation for User Story 1
- T024 [P] [US1] Implement untagged directory selection service in
backend/src/services/untagged_queue.rs - T025 [P] [US1] Implement collage sampler in
backend/src/services/collage_sampler.rs - T026 [US1] Implement keep decision (move to kept root) in
backend/src/services/ops.rs - T027 [US1] Implement delete preview for untagged directories in
backend/src/services/preview_action.rs - T028 [US1] Implement delete confirmation for untagged directories in
backend/src/services/ops.rs - T029 [P] [US1] Add API endpoints for untagged review in
backend/src/api/untagged.rs - T030 [P] [US1] Add API endpoints for untagged delete preview/confirm in
backend/src/api/untagged_delete.rs - T030a [P] [US1] Add list-file match selection payload handling in
backend/src/api/untagged_delete.rs - T031 [P] [US1] Create collage UI page in
frontend/src/pages/untagged-collage.svelte - T032 [P] [US1] Create resample and decision controls in
frontend/src/components/untagged-controls.svelte - T032a [P] [US1] Add list-file match selection UI in
frontend/src/components/list-file-matches.svelte - T033 [US1] Wire untagged review API client in
frontend/src/services/untagged_api.ts
Checkpoint: User Story 1 fully functional and independently testable
Phase 4: User Story 2 - Whitelisted Media Triage (Priority: P2)
Goal: Review whitelisted media items one at a time with safe per-file deletion
Independent Test: Can scope triage to all or one user, order by random or largest, keep or delete items with confirmation, and auto-advance
Implementation for User Story 2
- T034 [P] [US2] Implement whitelist triage queue in
backend/src/services/triage_queue.rs - T035 [P] [US2] Implement ordering strategies in
backend/src/services/triage_order.rs - T036 [US2] Implement per-file delete preview in
backend/src/services/preview_action.rs - T037 [US2] Implement per-file delete confirmation in
backend/src/services/ops.rs - T038 [P] [US2] Add API endpoints for triage in
backend/src/api/triage.rs - T039 [P] [US2] Create triage UI page in
frontend/src/pages/whitelist-triage.svelte - T040 [P] [US2] Create triage item viewer component in
frontend/src/components/triage-item.svelte - T041 [US2] Wire triage API client in
frontend/src/services/triage_api.ts
Checkpoint: User Story 2 fully functional and independently testable
Phase 5: User Story 3 - Audit Visibility and Safe Configuration (Priority: P3)
Goal: View audit history and manage required configuration safely
Independent Test: Can view recent audit entries and update configuration with validation, with read-only mode enforced
Implementation for User Story 3
- T042 [P] [US3] Implement audit history query in
backend/src/services/audit_log.rs - T043 [P] [US3] Implement configuration CRUD in
backend/src/api/config.rs - T044 [P] [US3] Add audit history endpoint in
backend/src/api/audit.rs - T045 [P] [US3] Create audit history UI page in
frontend/src/pages/audit-history.svelte - T046 [P] [US3] Create configuration UI page in
frontend/src/pages/configuration.svelte - T047 [US3] Wire audit/config API clients in
frontend/src/services/admin_api.ts
Checkpoint: User Story 3 fully functional and independently testable
Phase 6: Polish & Cross-Cutting Concerns
Purpose: Improvements that affect multiple user stories
- T048 [P] Add touch-friendly styling and swipe cues in
frontend/src/components/touch.css - T049 Add NixOS module skeleton in
nix/module.nix - T050 Add module options and validation in
nix/module.nix - T051 Add systemd service wiring in
nix/module.nix - T052 Add documentation for safety rules in
docs/safety.md - T053 Add documentation for list-file identity rules in
docs/list-file.md - T054 Add documentation for testing expectations in
docs/testing.md - T055 Add phase testing guide for Phase 0-2 in
docs/testing/phase-guides.md
Dependencies & Execution Order
Phase Dependencies
- Setup (Phase 1): No dependencies - can start immediately
- Foundational (Phase 2): Depends on Setup completion - BLOCKS all user stories
- Safety & Compliance (Phase 2.5): Depends on Foundational completion - BLOCKS all destructive workflows
- User Stories (Phase 3+): Depend on Safety & Compliance completion
- User stories can then proceed in parallel (if staffed)
- Or sequentially in priority order (P1 → P2 → P3)
- Polish (Final Phase): Depends on all desired user stories being complete
User Story Dependencies
- User Story 1 (P1): Can start after Safety & Compliance (Phase 2.5)
- User Story 2 (P2): Can start after Safety & Compliance (Phase 2.5)
- User Story 3 (P3): Can start after Safety & Compliance (Phase 2.5)
Within Each User Story
- Services before API endpoints
- Endpoints before UI wiring
- UI components before page integration
- Story complete before moving to next priority
Parallel Opportunities
- All Setup tasks marked [P] can run in parallel
- All Safety & Compliance tasks marked [P] can run in parallel (within Phase 2.5)
- Within a story, tasks marked [P] can run in parallel across different files
Parallel Example: User Story 1
# Launch service and UI tasks for User Story 1 together:
Task: "Implement collage sampler in backend/src/services/collage_sampler.rs"
Task: "Create collage UI page in frontend/src/pages/untagged-collage.svelte"
Implementation Strategy
MVP First (User Story 1 Only)
- Complete Phase 1: Setup
- Complete Phase 2: Foundational
- Complete Phase 2.5: Safety & Compliance
- Complete Phase 3: User Story 1
- STOP and VALIDATE: Validate untagged review workflow end-to-end
Incremental Delivery
- Complete Setup + Foundational + Safety → Foundation ready
- Add User Story 1 → Validate independently (MVP)
- Add User Story 2 → Validate independently
- Add User Story 3 → Validate independently
- Add Polish tasks as needed
Parallel Team Strategy
With multiple developers:
- Team completes Setup + Foundational together
- Once Safety & Compliance is done:
- Developer A: User Story 1
- Developer B: User Story 2
- Developer C: User Story 3
- Stories complete and integrate independently