Version 0.3.0

Author: ismartcoding

.cursorrules

@@ -81,14 +81,22 @@ PlainNAS is a Go-based NAS (Network Attached Storage) system with a Vue 3 web fr
 - Do **not** add Windows/macOS fallbacks, multi-platform abstractions, or non-Linux build stubs unless explicitly requested.
 - It is acceptable for non-Linux builds to fail; correctness on Linux takes priority.
 
+## Linux-Only File Naming
+- Prefer **generic filenames** (e.g. `storage_mounts_list.go`) over `*_linux.go` suffixes for new files, since this repo is Linux-only.
+- Only use OS-suffixed filenames when a build tag split is truly required (rare here) or when matching an existing established file pattern.
+
 ## VS Code / Copilot Rules
 - If you change application behavior or logic, update the relevant Markdown docs in `docs/` (preferred) and/or `README.md` (keep docs in sync with code).
 - Prefer minimal, readable, maintainable code; avoid unnecessary abstractions and duplication.
 - Do not add compatibility/migration/backfill code unless explicitly requested; it is acceptable to require deleting/rebuilding the DB for development workflows.
 - Prefer index-backed fast paths; avoid full scans and N+1 patterns.
 - Prefer root-cause fixes over workaround logic (e.g., extra guards/dedup that mask bugs). If an invariant is broken, fix the source and let issues surface during development.
+- **Timeouts are not yours to “tune”:** Do **not** change network/HTTP/SOAP/GraphQL timeout values (or add new extended timeouts) unless the user explicitly requests it. Treat timeout changes as behavior changes.
+- **Fail-fast default:** When timeouts are needed, prefer small, conservative values (e.g. 2–3s) and avoid “make it huge so it works”. If a longer timeout is required, make it configurable (config/env) and get explicit approval.
+- **No HTTP context in API requests:** Do **not** use `http.NewRequestWithContext(...)` / `req.WithContext(...)` for outgoing HTTP calls in API code paths (GraphQL/REST/SOAP/etc.) unless explicitly requested. Prefer `http.Client{Timeout: ...}` for request limits.
 - Keep `internal/graph/schema.resolvers.go` lightweight: resolvers should only validate/translate inputs and delegate to focused files (e.g. `internal/graph/*_api.go`). Do not put substantial business logic in `schema.resolvers.go`.
 - Frontend templates/HTML: keep markup flat and readable—minimize nesting, avoid wrapper `<div>`s unless needed, and do not add `class` attributes unless they are required for styling/layout/testing.
+- Frontend UI/UX (minimalism): prefer clean, spacious, “Google/Material-like” minimal UI—show only essential information, avoid redundant metadata blocks, keep copy short, and bias toward one clear primary action.
 - Do not remove the `<pre class="view-raw">` element; it is intentionally kept for troubleshooting.
 - Frontend styling rule: avoid copy-pasting the same scoped CSS across pages/components. If a style pattern is used in more than one place, extract it into an appropriate shared home (a shared stylesheet under `web/src/styles/`, a component-level style, or a small reusable UI component) and reuse it via classes/components instead of duplicating blocks in each `.vue` file. Keep `scoped` styles for truly view-specific tweaks only.
  - Prefer SCSS-style nesting for component-local complex popovers and help cards (for readability). When editing a component's `<style scoped>` block, prefer nested selectors (e.g. `.dm-help-pop { .title { ... } .meta { ... } }`) instead of long flattened selectors.

.github/copilot-instructions.md

@@ -13,10 +13,16 @@ PlainNAS provides a web interface for file browsing and media management, plus b
 
 - Web UI (served by the backend)
 - File browsing and basic file operations
+- Read-only preview for Office docs (`.doc`/`.docx`/`.xls`/`.xlsx`/`.ppt`/`.pptx`) served as PDF (optional; requires LibreOffice)
 - Media scan/index + search
 - Thumbnails (photo/video)
 - LAN discovery via `.local` (Avahi)
 - Optional SMB/Samba sharing
+- DLNA casting (TV cast)
+
+Docs:
+
+- [docs/dlna.md](docs/dlna.md)
 
 ## Why PlainNAS (vs image-based NAS OS)
 
@@ -34,6 +40,19 @@ Many NAS products expect you to flash a vendor image to a device/disk/USB drive
 
 If you want “no flashing images”, “no platform lock-in”, and a clean web UI that works out of the box, PlainNAS is a good fit.
 
+## PlainNAS vs other projects
+
+PlainNAS prioritizes performance efficiency, low resource consumption, and secure data transmission.
+
+| Project | What it is (stack / architecture) | Resource profile (CPU / RAM) | Security (API/data transport) |
+| --- | --- | --- | --- |
+| **PlainNAS** | General-purpose NAS • Go + Pebble + Vue 3 • single-process service | **Low**: single Go process; memory can stay in tens of MB; CPU mainly driven by file I/O | **High**: LAN API traffic secured with TLS + XChaCha20-Poly1305; not plaintext |
+| **Immich** | Photo/video management • Node (NestJS) + Postgres + Redis + ML services • multi-service | **High**: many always-on processes; often hundreds of MB idle; indexing/AI can saturate CPU | **Medium**: often HTTP on LAN or reverse-proxy TLS; internal APIs can be plaintext |
+| **PhotoPrism** | Photo management • Go + TensorFlow + MariaDB • multi-service | **Med–High**: DB + AI models; CPU/RAM rise significantly during indexing | **Medium**: usually plaintext HTTP on LAN; TLS via external reverse proxy |
+| **LibrePhotos** | Photo management • Python + Django + DB + AI • multi-service | **High**: Python runtime + model loading; higher memory footprint; CPU-heavy scanning | **Medium**: commonly plaintext HTTP locally; TLS depends on deployment |
+| **Lychee** | Photo gallery • PHP + MySQL/SQLite • web + DB | **Medium**: PHP-FPM + DB are long-running; higher baseline than single Go service | **Low–Medium**: plaintext HTTP by default; HTTPS via web server config |
+| **PiGallery2** | Gallery browser • Node.js • single service (heavier runtime) | **Medium**: higher baseline memory than Go; thumbnail generation spikes CPU | **Low–Medium**: plaintext HTTP by default; TLS via external proxy |
+
 ## Quick start
 
 **Recommended OS:** Ubuntu or Ubuntu-based distributions (Debian, Mint, etc.) are recommended for best compatibility and package support. Other modern Linux distributions may work, but Ubuntu is preferred for smooth installation and updates.
@@ -64,6 +83,12 @@ go build
 sudo ./plainnas install
 ```
 
+Optional (enables `.doc` / `.docx` PDF preview):
+
+```bash
+sudo ./plainnas install --with-libreoffice
+```
+
 This will best-effort install required packages (libvips, ffmpeg, samba, avahi) and write:
 
 - `/etc/plainnas/config.toml`
@@ -91,6 +116,18 @@ If you need to change it later, run:
 sudo plainnas passwd
 ```
 
+To uninstall:
+
+```bash
+sudo plainnas uninstall
+```
+
+To keep config and/or runtime data:
+
+```bash
+sudo plainnas uninstall --keep-config --keep-data
+```
+
 </details>
 
 ## Files and directories
@@ -158,6 +195,7 @@ go generate ./internal/graph
 - File conflicts (copy/paste & upload): [docs/file-conflicts.md](docs/file-conflicts.md)
 - Tags: [docs/tags.md](docs/tags.md)
 - Thumbnails: [docs/thumbnails.md](docs/thumbnails.md)
+- Performance benchmarks: [docs/performance-benchmarks.md](docs/performance-benchmarks.md)
 - Media items: [docs/media-items.md](docs/media-items.md)
 - Events (audit log): [docs/events.md](docs/events.md)
 - LAN share (SMB/Samba): [docs/samba.md](docs/samba.md)
@@ -166,11 +204,12 @@ go generate ./internal/graph
 
 Tested setup:
 
-- NanoPi R4S (4 GB RAM)
+- NanoPi R4S (4 GB RAM) or NUC-C3 L4 (J3160 + 8 GB RAM)
 - USB Type-C to SATA 3.0 controller (5-port)
 - 2 × SATA hard drives
 - OS: [Armbian for NanoPi R4S](https://www.armbian.com/nanopi-r4s/)
 
-<img src="./images/r4s.png" width="240">
-<img src="./images/usb-controller.png" width="180">
+<img src="./images/r4s.png" width="200">
+<img src="./images/nuc-c3-l4.png" width="240">
+<img src="./images/usb-controller.png" width="200">
 <img src="./images/disk.png" width="100">