`match_converted` — file/folder fully matched, source is a Google Doc exported to dest

Shallow `compare()` method also updated for consistency

Dest files claimed by Phase 2 are marked `match_converted` in dest entries too

Only runs when source is a Drive remote (`isDriveRemote()` made public)

Phase 2 matches by name only against unmatched dest files → new status `match_converted`

After Phase 1 (standard name+size matching), a new Phase 2 handles unmatched source files with `size=-1`

`Adam Dawid tekst.docx` exists both as Google Doc and uploaded .docx file — rclone logs "Duplicate object found in source" and skips one

Google Docs show as `-1 B` size in file browser (could show "Google Doc" label instead)

`TransferBar.vue`: Shows green/orange/red based on status + error_count

`MonitorTransferJob`: 3-way status: success → Completed, failure + transfers > 0 → Completed (with error_count), failure + 0 transfers → Failed

Applied to both `executeCopy()` and `executeSync()`

Example: ancestor `/_KURSTEAM` + folder selected → effective source `/` → rclone preserves `_KURSTEAM/` structure

When a selected folder's path equals the computed ancestor, moves ancestor up to parent

New `computeSourcePath()` function in App.vue

Listing still shows all Google Docs; copy/sync now exports them correctly

New `isDriveRemote()` helper detects Drive remotes by prefix (`gdrive*`, `sa-*`)

Added per-request `_config: {drive-show-all-gdocs: true}` in `RcloneService::listFiles()` and `RcloneService::listRecursive()` for Drive remotes only

Removed `--drive-show-all-gdocs` from `/etc/systemd/system/rclone-daemon.service`

Non-blocking: uses fire-and-forget clone to avoid delaying Vue

Works for both fetch and XHR (axios) code paths

Served instantly if Vue's SPA re-render requests them in cycle 2

PROPFIND/REPORT responses from cycle 1 are intercepted and cached

Kept: user_status, notifications, recommendations, avatar

Removed OnlyOffice (returns 412 CSRF, not worth pursuing)

Added folder-tree sidebar endpoint (140ms)

Changed `#vue-file-manager` from `height: calc(100vh - 56px)` to `flex: 1`

Override `.main-content` and `.page-content` via `<style>` block in `index.blade.php`:

Added `min-height: 0` to `.file-tree-wrapper` (flexbox shrink fix)

On change: persists to settingsStore (auto-saves to localStorage via `fm_last_accounts`)

On mount: reads from `settingsStore.lastUsedAccounts[panelId]`, falls back to first account

Uses existing `selectedPaths`/`toggleSelect`/`selectAll`/`deselectAll` from filePanelStore

Selection count shown in status bar

Select-all checkbox with indeterminate state in column header (FileTree.vue)

Individual checkbox per row in FileTreeRow.vue

Positioned above toolbar in each panel

Shows account name, email/server_url, provider label

Shows provider icon (Google Drive img / Nextcloud FA icon)

New `Account.ts` type definition shared across Vue app

Toolbar.vue uses `<optgroup>` grouped by provider+email (matches /transfers page)

FileManagerController now passes `provider`, `email`, `team_drive_id`, `group_folder_id`

v1.2: Root Cause 3 resolved (NC 32 frontend sequential loading), session #3 benchmarks, redis session locking, G-015 (NC 32 sequential loading), G-016 (redis session locking minimal impact)

v1.1: comparison table with hsal, NPM config, Caddy, OnlyOffice, performance investigation, G-010 through G-014

`coordination/experts/05-operations/nextcloud-nativja/EXPERT-nextcloud-nativja-v1.2-20260226.md`

**Applied:** `redis.session.locking_enabled = 0` in redis-session.ini (marginal, NOT persistent in AIO)

**Session #3 ruled out:** redis session locking (marginal effect), OnlyOffice (no effect), groupfolders (no effect), JS bundle sizes (nearly identical), PHP-FPM workers (14 active on nativja vs 2 on hsal)

This is NC upstream architecture, not configurable

NC 31 total load is same (~5.94s) but renders file list progressively at ~2s (feels 2x faster)

Each group: ~200ms server + ~800ms network/proxy round-trip = ~1s wall-clock. Total: ~5s.

NC 32 Vue.js frontend sends AJAX requests in 5 sequential groups, each waiting for previous

Server is NOT the bottleneck. Nativja is FASTER per-request than hsal: