logicdx342/shelflife

1. Overall shape: ShelfLife is a desktop application built as a Tauri shell around a Svelte frontend and a Rust backend. The frontend handles navigation and state presentation, while the Rust side owns filesystem monitoring, rule evaluation, persistence, and any action that can change files.

2. User-facing surface: The Svelte app is organized into pages for dashboard, review queue, dropzone, browser, rules, audit, and settings. Shared shell components such as the sidebar, title bar, and status bar frame these views. The UI is heavily componentized and uses a local component library built from shadcn-style Svelte primitives.

3. Frontend data boundary: Frontend code talks to the backend through src/lib/api/* wrappers for config, files, rules, dropzone, and triage. Reactive stores in src/lib/stores/* hold the current file set, rule set, audit trail, and notifications, while liveSnapshots suggests the UI is fed from live backend snapshots rather than directly inspecting the filesystem.

4. Core domain model: The backend models center on tracked files, rules, dropzones, audit events, configuration, runtime state, origin/source metadata, and previews. The key product concept is file lifecycle state: files move through freshness/decay states, can be pinned, and can be projected into preview mode before any destructive action.

5. Filesystem monitoring pipeline: The engine module is the operational core. It includes a watcher for OS file events, quiescence handling to avoid acting on files still changing, freshness tracking, and path/reconciliation logic to keep the runtime view aligned with the real filesystem.

6. Rule processing pipeline: Rules are interpreted by a dedicated rules subsystem (conditions, evaluator, explanation, regex_cache) and an execution layer under engine (rule_projection, rule_execution, rule_refresh). This separation indicates a deliberate split between deciding what would happen, explaining why, and performing the action.

7. Safety and preview flow: New rules begin in preview mode, so the app can calculate affected files without applying changes. That preview path is backed by the rule projection/explanation pieces, which feed the rule editor and test-result UI before a rule is activated.

8. Background runtime and scheduling: The runtime module contains scheduling and reconciliation logic, including a rule scheduler and a mock runtime for non-production scenarios. This suggests the app has a long-lived background control loop that periodically re-evaluates file state and rule eligibility, rather than only reacting to explicit user actions.

9. Persistence and history: The storage layer persists rules, tracked files, and audit records. The audit log is not just a UI feature; it is a durable subsystem that records file actions so users can review past behavior and undo supported operations.

10. External side effects: When the backend decides to act, it moves files to the system trash/recycle bin rather than deleting them outright. That behavior is central to the architecture: the backend is the only layer permitted to perform these side effects, which keeps the UI safe and non-destructive.

11. Dropzone and triage workflow: The presence of dedicated dropzone models, commands, and a dropzone-specific route indicates a separate intake path for newly arrived files. Triage commands likely move files from incoming handling into tracked/reviewed states, bridging raw filesystem events and rule-managed lifecycle.

12. App lifecycle and system integration: tray.rs, main.rs, and Tauri capability files show the app is designed to live in the background with system-level access constrained through Tauri permissions. The app is therefore a resident desktop service with a UI, not just a page-based application.

13. What to draw as the main boundaries: The clearest diagram should show:

• Svelte UI layer for dashboards, rules, audit, and settings

• Tauri command boundary as the only frontend/backend bridge

• Rust orchestration layer for watching, scheduling, reconciling, and rule execution

• Local persistence for rules, tracked files, and audit history

• Filesystem/system-trash side effects as the final external boundary

14. Supporting but non-central pieces: The repo also includes localization tooling, CI/release workflows, and a lightweight test/mock setup, but these support development and packaging rather than changing the runtime architecture.