# Implementation Plan: Archive Curator

**Branch**: `001-archive-curator` | **Date**: 2026-02-07 | **Spec**: /home/jawz/Development/gallery-organizer-web/specs/001-archive-curator/spec.md
**Input**: Feature specification from `/specs/001-archive-curator/spec.md`

**Note**: This template is filled in by the `/speckit.plan` command. See `.specify/templates/commands/plan.md` for the execution workflow.

## Summary

Build a safe, web-based curator for a local media archive where each subdirectory
represents a scraped user. The system provides two core workflows: untagged directory
collage review for keep/delete decisions (with list-file preview/removal) and
whitelisted media triage for single-file deletion with strict directory protection.
All destructive actions are previewed, confirmed, serialized, and audited. Delivery is
phased from a read-only viewer through deletion workflows, hardening, and NixOS module
maturity.

## Technical Context

**Language/Version**: Rust (stable toolchain)  
**Primary Dependencies**: Web API framework (Axum), UI framework (SvelteKit), OpenAPI tooling  
**Storage**: Local durable state store (SQLite) + append-only audit log file  
**Testing**: cargo test (unit/integration), API tests (HTTP), NixOS VM tests  
**Target Platform**: NixOS/Linux (local network, single-operator)  
**Project Type**: Web application (backend + frontend)  
**Performance Goals**: Visual review stays responsive; collage load and next-item
advance feel immediate for local storage  
**Constraints**: Safety-first, offline/local-network only, strict root boundaries,
read-only mode support, serialized destructive ops  
**Scale/Scope**: Large local archives with many user directories and large media files

## Constitution Check

*GATE: Must pass before Phase 0 research. Re-check after Phase 1 design.*

- Whitelisted directories remain protected from any directory-level delete
- All destructive actions include dry-run preview, explicit confirmation, and audit log
- Read-only mode disables all mutations while allowing browsing
- Destructive operations are single-writer and never concurrent
- Operations are bounded to configured roots; destructive ops never follow symlinks
- Default deletion is two-stage (trash/staging); hard delete is explicit + confirmed
- List-file edits are previewed, optional, atomic; exact-match removal by default
- UI surfaces directory state and recent audit activity for verification

**Gate Status**: PASS (requirements and plan explicitly enforce all constraints)
**Post-Design Re-check**: PASS (data model and contracts preserve all safety gates)

## Project Structure

### Documentation (this feature)

```text
specs/001-archive-curator/
├── plan.md              # This file (/speckit.plan command output)
├── research.md          # Phase 0 output (/speckit.plan command)
├── data-model.md        # Phase 1 output (/speckit.plan command)
├── quickstart.md        # Phase 1 output (/speckit.plan command)
├── contracts/           # Phase 1 output (/speckit.plan command)
└── tasks.md             # Phase 2 output (/speckit.tasks command - NOT created by /speckit.plan)
```

### Source Code (repository root)

```text
backend/
├── src/
│   ├── models/
│   ├── services/
│   └── api/
└── tests/

frontend/
├── src/
│   ├── components/
│   ├── pages/
│   └── services/
└── tests/
```

**Structure Decision**: Web application with separate backend and frontend to enable a
Rust API service and a touch-focused web UI while keeping filesystem mutations confined
to the operations layer.

## Complexity Tracking

> **Fill ONLY if Constitution Check has violations that must be justified**

| Violation | Why Needed | Simpler Alternative Rejected Because |
|-----------|------------|-------------------------------------|
| N/A | N/A | N/A |