## The core break

`Drives.vue` builds the right target path and passes it to the upload helper as a third argument:

```js
const path = dirPath ? `${dirPath}/${file.name}` : file.name;
await backend.uploadDriveFile(drive.name, file, path);
```

The backend only accepts uploads at `POST /files/<drive>/<path:filename>` (`upload_file(user_id, drive_name, filename, stream, mime_type)`), i.e. the composite name *must* be in the URL. Docs describe the helper as 2-arg (`uploadDriveFile(driveName, file)`) POSTing to `/files/<drive>`, which has no route. So the documented contract and the view disagree, and every upload (root or folder) fails. The view is right; the docs/wrapper are wrong. This is the same failure the doc already lists under "Known issues," but it's written as a bug report rather than as the correct interface.

Everything else in `Drives.vue` matches the documented REST API and shapes:
- `getDrives()` → `{id, name}` ✓
- `getDriveFiles(name)` → `{id, name, size, mime, created}`, consumed by `buildTree` ✓
- `deleteDriveFile(name, path)` ✓
- `driveFileUrl(name, path)` for both the `<a download>` and `window.open` ✓

So the *view* speaks the right API. The fix belongs in `backend.js` (accept the path, multipart-POST to `/files/<drive>/<path>`), and the "Frontend interface" section should document the 3-arg signature.

## Docs vs. backend (`drives.py`)

1. **`accessed_at` claim is false.** Docs: "Every resolve (download, metadata, delete) stamps `accessed_at`." Only `resolve_file` stamps it. `get_metadata` and `delete_file` never touch it.
2. **DELETE return value is wrong.** Docs: returns `{fileId}`. `delete_file` returns the removed absolute disk path (`abs_path`).
3. **`resolve_file` returns the wrong second value.** Docs say it serves bytes "with their stored mime type" and the docstring says it returns `(path, mime)`. It actually returns `(abs_path, file.id)` — the file id, not the mime. So mime cannot come from `resolve_file`; the route must look it up. Fix the docstring too.
4. **Id- vs name-addressing is undocumented.** The route table presents download/delete/metadata as drive+filename-addressed, but the functions are id-addressed: `get_metadata(file_id)` and `delete_file(file_id)`. Only `upload_file` takes drive+filename. The docs should note the extra filename→id resolution step.
5. **Ownership checks don't match the claim.** Docs: "Ownership ... is checked before any disk access." `resolve_file` checks it (badly — already noted for the `None` deref). But `delete_file` and `get_metadata` perform **no** ownership check at all; both work off a bare `file_id`. If the route doesn't guard them, that's a real authorization gap, and the doc overstates the protection.
6. **Listing routes aren't in `drives.py`.** The table lists `GET /files` and `GET /files/<drive>` as backend routes, but no `list_drives`/`list_files` exists here — the doc says "logic in `backend/src/drives.py`," which is therefore inaccurate for those two.
7. **Minor identity mismatch in the doc's own text.** It describes `DriveFile(id char(64) pk ...)` while `_generate_file_id()` is `secrets.token_hex(8)` → 16 hex chars. Harmless but the doc contradicts itself.

The already-listed "Known issues" (collision check querying `Drive` instead of `DriveFile`; `resolve_file` dereferencing a `None` drive) are accurate and match the code.

## Suggested ordering
- Fix `backend.js` upload (path arg + `/files/<drive>/<path>` POST); update the doc's frontend section to the 3-arg signature.
- Correct the doc's `accessed_at`, DELETE-return, and `resolve_file`-return claims.
- Decide whether `delete_file`/`get_metadata` need ownership checks (they currently have none) and document id-vs-name addressing accordingly.

---

# Task

Apply the fixes documented in the prompt above. This task is bounded on the files:  docs/drives.md, frontend/src/views/Drives.vue, backend/src/drives.py. You can only access those files, any read or exploration in another location is forbidden.